There are some key aspects that make “good code” stand out from the rest: easy to read, maintainable (easy to change, loosely coupled), easy to understand and… elegant.
Below are a few items that will definitely help you be a better Ruby (on Rails) developer.
- Follow the Coding Standards
A key component of writing “Good Code” is following the Coding Standards. Every developer should be familiar with them and be very strict about it. If you are a developer that follows them, the first thing that catches your eye when reviewing a pull request is everything that’s not in accordance with the Coding Standards. Of course, there will be team members that don’t agree with certain standards and use their own versions. In those cases, it’s best to update your Project Standards/Guidelines and make sure the entire team is aware of them.
Make your code SOLID
S.O.L.I.D is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin. It stands for:
- Single responsibility principle
- Open/closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle
It takes a certain level of expertise (exercise) to start coding with these principles in mind and sometimes it’s difficult to apply them. I find one of them, the Single Responsibility Principle, of the utmost importance because it steers you down the path of writing maintainable, loosely coupled code. Every developer regardless of their knowledge level or programming language should create methods, classes, modules that have a single central purpose.
If you’re mentoring people, think about teaching them this principle before anything else. Mastering the SRP takes a bit of time and initially one will lose dev time to correctly find that single purpose.
- Everything should be “skinny”
By “skinny” I mean two things: small classes, light functionality. When Rails got on the market there were no actual guidelines where to put the certain code and everything eventually got stuck in controllers and models, causing them to get “fat.” Here are a couple approaches to avoid that:
- Don’t be afraid to create Plain Old Ruby Objects (POROs). Having a class that does a single thing (SRP) is much better than having a controller do/know stuff that’s out of its scope. Plus you get to test everything in isolation. Same thing applies to models.
- Just don’t move stuff into concerns or modules. You’re just sweeping the dust under the rug. Visually the controllers/models are skinnier but the objects are still bloated with the functionality you extracted.
- Find concise names for everything
This is probably the most time-consuming step when writing code. Finding the correct names for your variables, methods, and classes is sometimes a real challenge and art. This is when many developers realize how badly they deviated from SRP. If you can’t find a simple name to describe the purpose of your context then your context does too many things. And not to mention that in Ruby, good names absolve the programmer from writing code comments.
- Avoid Metaprogramming
Metaprogramming is cool, fancy, powerful but not that healthy for your team. Look at your team members, at their level of experience, figure out if using it is too mind-boggling for them. It is very complicated especially for junior developers to understand and follow it. Your code should be easy to understand for everybody, not just for you.
- Audit your code
There are two outstanding tools (gems) that shouldn’t be missing from a Ruby developer’s toolkit: rubocop (for coding standards) & rubycritic (for code quality). Constantly check your code against them, enforce it in your teams, and automate it via git hooks and Continuous Integration. They will definitely hone your coding style and improve your project’s code base. Other gems that are worth mentioning: bullet, rails_best_practices, ruby-prof, rbkit.
- Don’t forget the tests!
Adding tests for your code is a must! They not only guard your code against bugs, they also help new team members to better understand the project. It’s not a weird thing for a Ruby developer to read the Functional Tests before any documentation. If you’re not doing this already, consider including it in your workflow (you’ll definitely have to increase the estimations a bit), but it’s a lifesaver. Check this Awesome Ruby for different testing tools. If you’re doing it, then look into adding more coverage – try to break your code, add more scenarios, etc.
Latest posts by Razvan
- A Guide to Writing Good Code in Ruby - October 2, 2017