Six rules to make Ruby On Rails code Crisp, Absolute and Clear!

14 Aug 2018
Six rules to make Ruby On Rails code Crisp, Absolute and Clear!

In my coding lifetime, I have enhanced and improved my coding style after client feedback and guidance. I have learned over the years of time, that there aspects and points that has utmost importance in the coding of Ruby on Rails (RoR) application.

We as developers start writing code without actually analyzing and understanding the code requirement as well. A messed up code is no one’s favorite and not to be delivered.

I am sharing my thumb rules that will surely help you as it did to me.


Rule No. 1: Indent your code

What if you are given a much messed up code to update? I am sure you will get frustrated; in order to write very clear code keep it well indented. In Ruby on rails, though the auto-generated code is four space indented style we should use two spaces to intend our block of code as this is most widely adapted style. This improves the readability of our code.


Rule No. 2: Name it well!

Naming convention should be followed as this is helpful for us to understand the purpose of it and at certain places, active record in ruby also works on the basis of names.

Active record uses the same naming convention in order to find out how the mapping between the models and database tables are created.

Say for example a class “Category”, should have a database table called “Categories”. The rails pluralization mechanism is very powerful such that it is capable of pluralizing both regular and irregular words.

When it comes to naming a variable, you should follow CamelCase form, which says that the first word should start with a small letter and the next word should start with a capital letter, e.g. “categoryOne”.

When the table name has two words, it should be separated by “_” , e.g. “book_categoryies”. When it comes to model class, it should be singular with the first letter of each word capitalization e.g. “CategoryBook”.

Similarly, the name of methods should be such that it should define the purpose of that method, for e.g. “category_list”.


Rule No. 3: Less If else, Less complex

If else statement is a block of condition where you check the condition if it is true or false.

Using the number of if-else statement creates makes the code bulky. It will increase the number of lines in the code, which can be reduced or should not be used at all. It also makes the code complex and not easy to understand.


Rule No. 4: Use of a number of variables

What do variables do in rails? It allocates the memory for which it is assigned for. When the expression can be directly assigned or can be directly passed, a variable should not be used as this will be the unnecessary allocation of memory, unnecessary declaration of a variable.

In Ruby on rails development, we have four different types of variables global variables, class variables, instance variable and local variables.

Global variables are accessible globally in the application which means it can be modified from any part of the program hence it let to lack of security of our code.

Hence it is recommended not to use global variables.

Always try to replace instance variable with local variable as local variables are accessed locally which ensures the security of our code.


Rule No. 5: Put-up a comment there

Comments are the description written in the source code within the special character so that it should be ignored by the compiler.

What if, you get a new project with some classes having methods in it? Will you be able to understand the purpose of it?

Even, if the method name is good enough? No, sometimes only method names do not help in recognizing or understanding the main purpose of the method or how it works, hence your method should be well commented in order to let others also understand its basic purpose.


Rule No. 6: Don’t put too much logic in the view, make use of helpers, create them!

Views are specially meant for displaying the data hence it should not have too much logic, this can be done by making use of helpers, if the piece of code is used many times in a view, make a helper and call it in a view.

So, these are my six thumb rules while writing code, from the time that I have become the developer. These have helped me and can be taken as consideration to make your code scalable, robust and secure.

This will add sparkle to your code, which will eventually make your client happy! :)  

If you have a different lookout, let me know your views, in the comments section below.

Leave a comment:

Recent Blogs
Contact-Us Contact-Us
Newsletter Newsletter