Rails Development: Coding Conventions & Best Practices.

What’s in a name

Structural Naming


  • A loop with a temporary variable.
  • A loop with a nested conditional.

Let’s try refactoring them

General Practices

  • What if we devise a set of rules to follow while coding, that later on reduces our efforts in refactoring.
    The most basic and important point is FORMATTING. It sounds like the most obvious and easy thing to do but it’s very important to format your code correctly. In terms of code readability, understanding for future references, and also while resolving conflicts that occur while merging two different branches.
  • When writing an if condition with multiple sub-conditions, always try ordering them such that the least effort is required. For example,
  • If you're a big chunk of logic, which is going to revolve around a single functionality, try breaking that into multiple smaller methods. It increases reusability, plus it becomes easy for a new developer to understand the code easily. Instead of writing everything in a single method, and giving it the look and feel of complex logic, divide it into smaller readable chunks of methods.
  • Comment your magic code. Ruby provides a lot of metaprogramming methods, which help reduce your effort and are time friendly. But they’re not always that easy to understand when you want to refer back to them, it’s always a good idea to add appropriate comments so that when you come back later to take a look, it’ll be easier for you to reconnect.
  • Use before_filter, instead of repeating yourself in the controller.
  • Use model callbacks to avoid writing too much code into controllers for the actions that revolve around the basic CRUD operations.
  • FORMATING: there are certain gems which makes your life much easier : awesome_print ; pretty print ; rubocop.
  • Always follow the practice of Code Review in Git. Code that’s written by one developer, should be reviewed by other team members before merging with the main branches, as that helps eliminate any potential errors or unexpected outcomes. It also helps in keeping every member informed and updated about what their colleague is working on.
  • Statements that extend post 80 characters should be broken down into next lines so as to avoid scrollbar when viewing code in other mediums like GitHub.
  • When committing code to your repository, git diff tells me what you did, your commit message should say why you did that.
  • Unit testing is always a good idea to ensure the functionality is working as you expected. Help by Aspect: Rails by default generates one helper for every controller. Eliminate them and try using helpers which are aspect-oriented like ; -> link_helper –> menu_helper
  • As per the convention of MVC, one should avoid making calls to the database from the View layer. Move that part of your code into controllers to ensure the separation of concerns.
  • Reduce calls to databases. If an often visited page triggers more than a couple of calls to the DB, it’s worth spending a little time to reduce the number of calls to just a few. In many cases, this is just a matter of using .includes() or .joins().
  • It becomes a tedious task to check your model structure time to time, as a resort to that, include your model structure at the top of the file as a reference.



Ruby on Rails Development Company

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store