Oops... your message was not sent

Your message has been successfully sent

Jetruby Blog
Hire Us
Featured Technical Stories Based On Our Experience
Custom Development, Rails

50 Most Common Rails Mistakes: The Ruby Way

It’s been a while since we’ve rolled out our previous article about the most common Rails mistakes that beginner developers usually make. In this regard, we aren’t going to bother you with too much of introduction and get straight to the point. This article will be dedicated to the standard approaches to Ruby development which are also called “the Ruby way”. As usual, the most critical mistakes are highlighted with RED. So, let’s find out what exactly newbies do wrong/forget to do or don’t do at all.

They misuse predicates

A predicate is a method that answers a specific question and always returns either “yes” or “no”. It’s not supposed to affect any other piece of code or perform any additional actions. According to the Ruby on Rails style guides, predicates are followed by a question mark at the end of the method name.

They forget to explicitly use “present?”, “blank?”, and “nil?”

Using “present?”, “blank?”, “nil?” etc. for validation is considered a good practice even you’re totally sure the code is going to work anyway. Keep that in mind.

They don’t use memoization

common rails mistakes
An instance variable is considered “nil” if it’s not declared. With that in mind, you can leverage memoization. Using the first option in the code sample below will perform four requests: two for the user selection, one for the articles selection, and one for the courses selection. However, if you look at the second option, you will see that the number of requests is now down to three: one for the user selection, one for the articles selection, and one for the courses selection.

They forget that first come symbols, then single quotes, and then double quotes

Ruby on Rails guides insist on using minimum syntax. However, following this notion is not a must. If there should be single quotes – we recommend using double quotes, not screening.

They use some random numbers and lines

One of the rules you need to remember at all times is that there shouldn’t be any random numbers or lines in your code.
common rails mistakes

They often choose short or confusing words to name constants

Using short names for constants leads to poor readability and may even cause conflicts. Moreover, the code eventually becomes completely illegible. The only exception may be when creating migration in a table or generating a form in a view.

They excessively use postconditions

Postconditions allow you to make your code even more laconic and readable. However, in some cases, it’s better to avoid using them. For example:

  • when you know the postcondition can be lost in the current code line;
  • when it’s the main condition and, thus, has to be as visible as possible.

They forget to remove unused parameters and variables, and other unused code

It’s extremely important remove unused code. Why? Because doing that becomes much harder over time especially for other developers.

They don’t use “public_send”

Nearly 90% of all the examples on the Internet refer to the “send” method when invoking a method dynamically. But there is also a similar method – “public_send”– which is even more preferable in some cases.

They write long and illegible conditions

Remember: long conditions – especially the ones starting with “unless” – are very close to unreadable. You can give them proper names by placing them into methods.

They think less code is always better

Ruby code should be easy to read and look into. That’s why you should always write your code with the readability aspect in mind. For example, you can outline an important condition by breaking it down to few more lines.

They use obsolete syntax

Despite there are still quite many guides in which you can find old syntax, we recommend sticking to its new version. Firstly, it’s shorter and easier to read. Secondly, it’s better to adhere to a single code style.

They excessively use “when” and “if”

They don’t use rubocop and other tools for code analysis

Rubocop is a great tool that allows you to search for syntactical and other kinds of mistakes.

They don’t fully understand the point about commenting

Ruby is considered a very high-level language that doesn’t need commenting. Instead of writing another comment to your code, try making it more readable.

Wrap up

This was the third part in the series of articles about the most common Rails mistakes that many beginners face on a regular basis. Hope you’ve enjoyed our tips and pieces of advice. If so, don’t forget to tell your friends about the article by clicking these fancy little buttons below! And if you have any development-related questions, you can always ask our experts in the comment section. Stay tuned!

P.S. You can find the Russian version of the article here.

This post created by
Web Development Department
Professional website designing and development.
  • Daniel Gaytán

    Thank you for this article, it’s very explicit, easy to follow, read and integrate in common practices.

    Nit pick… you used send instead of public_send in the example of “They excessively use “when” and “if””.

    • Hi, Daniel! We’re glad to hear that! As for your notion, public_send is better than send only in some cases.

  • Giorgio Torres

    I’m a Ruby on Rails dev for not so long. But during my journey I already notice some peculiarities.
    First I congratulate the author about the great article. Very informative and well written.

    But I’d like to suggest a correction or to append a notice for the “About the use of present?, blank? and nil?” section.
    If in the given snippet was `courses` in the place of `course`, and it was an Array or an ActiveRelation (courses = Array.new or some instance of ActiveRelation) both given sections, wrong and right, would be testing very different things.

    In section ‘wrong’ would be testing if courses variable has been initialized (defined). In section ‘right’ would be testing if courses has any element, even though it has already initialized.
    Semantically speaking, I don’t know if I agree that `[].present?` should really result `false`. The way I see `[].present?` should result to true, but that’s not the way it is implemented. Same happens for `blank?`, but not for `nil?`. And for collection types I would add `any?` and `empty?` methods, which I prefer to test `courses.any?` instead of `courses.present?`.

    Thank you!

  • Ruurd Pels

    From what I am reading here I conclude that the found faults are hardly specific to Rails or Ruby. Many of the issues are quite universal.

  • Anne_Ominous

    No, the “new syntax” is NOT easier to read. It is literally more difficult for the brain to interpret.

    Precisely because it is inherently inconsistent.

    :mysymbol and {mysymbol: 3} use different notations for the same thing, and therefore the brain takes extra time to process them.

    On the other hand, :mysymbol and {:mysymbol => 3} are consistent, and literally easier to read, because the brain does not have to process inconsistent notations before realizing they are the same things.

    The only “advantage” of the “new” syntax — and I’d hesitate to even call it an advantage — is that half the time it looks more like JSON.

    You can call the “old” syntax a “code smell” if you want, but from a human engineering (or industrial psychology) standpoint, it is the “new” syntax that stinks. New is not always better.

  • Giorgio Torres

    First I’d like to congratulate you for the great article. Very informative and well written.
    However, I also would like to point some topics out about the section They forget to explicitly use “present?”, “blank?”, and “nil?”

    I’m going to use a counterexample using almost the same code as you used to expose a pitfall on the use of the same methods in Rails.

    Let’s exchange the course method/variable to courses, where this is some collection type, may be Array or an ActiveRelation.
    If you check “courses.present?” it will return false case the collection is empty. I totally disagree with that implementation. In fact I don’t like, because Ruby is very readable and this design decision about the “present?” method was very poor, I believe, and against Ruby’s way.
    So, if you want to check if the courses variable is not nil, i.e., it has some value, independently if the collection has elements or not, you will have to check using the same construction in your ##WRONG## example section.

    This is just something that I think it is worth it to point out because can lead to semantic errors in someone else’s code.

  • In ‘They excessively use “when” and “if”’, every single line is a perfect example of DON’T:

    def somethod(name)

    def process_a

    def process_b

    Please, never ever do that. Besides this code is inconsistent (ruby developer would either use `private` methods for `process_x`, or `public_send` in `somemethod`,) it results in a totally unreadable and hard-to-understand error message when future us will extend it with `process_c`. The correct solution is:

    case name
    when ‘a’
    when ‘b’
    raise NotImplemented, “Method #{__callee__} was called with an unsupported #{name} parameter.”

New Articles