Rails Best Practices: introduction

I’ve decided to dedicate a series of posts to Rails Best Practices because I think it is important to share in order to continuously improve the way you write programs.

Write these posts will also be an opportunity for me to investigate my knowledge, so I invite you right now to follow this trip with me and contribute with your comments.

This first post is just an introduction in which I want to highlight the advantages of writing Ruby on Rails applications following the Best Practices rules. In the following posts of this series I will try to explain the basics concepts to write better and more manageable code through concrete examples.

But now I’ll summarize the main benefits from following best practices:

Readability: a code more readable and clear is especially useful in projects involving multiple developers but also on individual projects. Did you ever faced with some chunk of code you wrote a few months before? It was quite clear and readable?
Flexibility: well written code is generally more modular, hence easier to adapt to new requirements or to changes request by the client. But flexibility also makes it easier to reuse some features rather than a block of code already wrote in the past on new projects.
Maintainability: a modular and DRY code is easier to correct and easier to understand.
Testability: write code according to best practices makes it easier, as we shall see in the next post, the flow of operations performed in the controller. Thus, even test methods will be easier to write.

In the next post will begin to see how to move pieces of code from the controller to the Model, according to the practice in the world rails is called “Fat Model – Skinny Controller“.

The arguments of the later posts will be instead: