Ruby on Rails – Programming Best Practices

Don’t Repeat Yourself

I’m sure most of you have heard of the DRY principle. It is something Rails has taken to heart, and I’m very glad it has. By not repeating yourself you can freely change something in one area of the program without worrying if you need to make the same change in another area. Not only that, but keeping the code DRY usually leads to better design.

Sometimes it is difficult to find duplication in your code. If you find yourself making a similar change in multiple places, you should first remove this duplication so you only need to make the change in one place.

This principle should not only be followed in code, but in your database and other areas as well. If you are repeating logic or data in the database, consider changing the design so it is not repeated.

That said, there are times when repeated data is good. For example, if you are building a cart system, the price for the items in the cart should be stored in a separate field than the price for the product. This allows you to change the price of the product without effecting all previous orders.

 

Stick to the Conventions

Another extremely important practice taken up by the Rails community: stick to the conventions. From naming variables to structuring files, there are conventions on how to do these things in Rails. If you are unsure of the conventions, check out a Rails book or tutorial – most of them stick to the conventions.

The advantages of sticking to conventions are almost too numerous to count. In fact, it deserves its own article.

 

Optimize Later

Performance is a major concern for many people switching to Rails, and rightly so. It is true that Rails is generally slower than other web frameworks. However, it is very scalable, so do not worry about it at the beginning. If you are a large corporation that needs to handle thousands of requests per second, then you may have something to be concerned about, but for the majority of us performance does not need to be considered until near the completion of the application.

Any optimization done early requires guessing. Instead you should wait until you know where the bottlenecks are. Optimizing usually requires extra/complex code, and you should keep the code as clean and simple as possible. Therefore, only optimize where necessary. Also, any performance testing should be done in the production environment, as this adds some optimizations which are usually turned off in the development environment.

Above all else, don’t let fear of poor performance inhibit you from making good design decisions! There are usually good ways to optimize while still keeping the good design, but these ways are hard to see unless you have a good design already in place. In short, don’t worry about performance while designing.

 

Humans First

Code for humans first, computers second. In other words, make the code as readable as you can. No, I’m not talking about cluttering it with comments. Most code should be understandable without comments.

How do you make the code more readable without comments? Rename variables, move code into classes/methods, etc. Try to give variables and methods concise, yet descriptive names. Do not abbreviate the names unless the abbreviation is very common.

 

Test Driven Development

You’ve heard it said: “Rails makes testing easy, so you don’t have any excuses not to do it.”. Well, in my opinion, testing is never easy – it is just easier in Rails.

Seriously, if you have not tried test driven development, give it a go. Automated tests are a godsend! I find myself rarely going to the web browser anymore to test things out. I just know it works because all of the tests pass. I wouldn’t dare code a mildly complex application without testing anymore. It will take some time to get used to testing, but the benefits are far worth it.

 

Refactoring

This is my favorite best practice, and for good reason. Refactoring ties all of the things in this list together. Simply put, if you want to become a better programming, learn Refactoring. Normally the first time you write a piece of code, it is messy. Whatever you do, don’t leave the messy code as is. Even if it works correctly, it will be a headache to maintain. You should take some time to clean up the code, make it readable, and improve the design.

Make it beautiful.

Last edited by ryanb (2006-10-31 00:13:39)

The original Refactoring book is definitely recommended reading. There is also Refactoring Databases.