Oops... your message was not sent

Your message has been successfully sent

Jetruby Blog
Let's talk!
Featured Technical Stories Based On Our Experience
Custom Development, Rails

50 Most Common Ruby on Rails Mistakes: Controllers

In our previous article, we enlisted the most common Ruby on Rails mistakes that beginners make when working with model and database. Today’s post will be entirely dedicated to controllers and all the related mistakes you should avoid. As usual, the most dangerous ones are highlighted with red.
Let’s go!

They use instance variables in controllers

Quite often beginners declare all the variables in controllers as instances even if it may not be required. The problem with instance variables is that if you make a mistake, you won’t get the error message. A good practice here is to use one or two instance variables per action. If you need more, group them in Presenter.

They don’t specify the HTTP response status in API controllers

Designing API you must specify the response status. Thus, the client application is able to know about the previous actions before processing the response body.

Initialize or look for objects without parent connections

The current object’s parent can often be available in the controller. For example, the user should be able to edit only his own objects in the personal account. The range of lessons that can be found is limited by the given course.

Using this simple approach you can make the app more stable and increase its security. What is more important, it will help you to avoid an enormous amount of errors. This approach applies not only to personal accounts but also to nested routes. As soon as you’ve found the parent, look for the child object.

They use instance variables in partials

The problem with using instance variables in partials is that as soon as the project starts growing everything turns into a mess. It will be really hard to tell which variable came from where. Thus, supporting all of the dependencies becomes impossible.

They don’t use before_action

The only logic that can be in the controller’s actions is their own. Whether you need to perform some preliminary actions or check user access rights – this must be in the before_action. In addition, it will allow you to avoid code duplication.

They don’t use helper methods

Helpers can greatly simplify things. For example, remote forms are often used in the application. You can add this parameter into each form, or

Furthermore, you can use helper methods to hide logic from views.

These were the most common Ruby on Rails mistakes beginners make when working with controllers. Next time, we are going to speak about The Ruby Way and the best coding practices.

Stay tuned and don’t forget to share the article in your socials! =)

Here is the Russian version of this article.

Ilya Matanov
This post has been contributed by:
  • Jai Kumar Rajput

    You guys are amazing. Doing great job @Jetruby… Thanks again guys

  • Julien

    « Initialize or look for objects without parent connections » : be stateless when possible. Instead of using current_user.courses.find, just do Course.find and then check authorization (eg with Pundit). It’ll be helpful the day a user share an URL to an administrator.

    It’s also a good way to check your routes: prefer a stateless « /users/:id/courses » over « /courses » that depends on current_user. It will also help for http caching.

  • Pablo C. V. Bello

    I think it is better status: 201, to create HTTP response

    Great article

    • TY for noticing! We’ve corrected it.

  • Pingback: 50 Most Common Ruby On Rails Mistakes: Controllers – sskumatov()

New Articles