Thursday, January 21, 2016

Do not change conventions without good reason

Rails framework privileges convention over configuration (
We hear this all the time, but what exactly does this mean?
This means that when you are using Rails framework, you just don’t need to care about naming many thing, where putting many things, where this or that resource will be searched for and so on. And you don’t need to care about these things because the Rails framework ‘knows’ these things.
Let’s take a look at tables, for instance, just to help us make it clear.
If I create a model named User, this model will be related to a table named ‘users’ in my database. I don’t need to define this in a configuration file or something. A model is, by default, related to a table with the same name in plural  form and lowercase.
And since we are talking about a table in a database, my database itself will ‘automagically’ receive the name of my application, followed by _test, _development and _production, depending on the environment I’m using.
Even before that… when I decided to create the model User by myself, not using ‘rails generate model’, I put my user.rb file, with the model code, inside app/models directory. Why? Because it is there that Rails will look for it by default!
Default is the great word here. Convention over configuration means, stating it in a simple way, that Rails framework has lots of defaults. Defaults for almost everything.
Convention helps us a lot, because it allows us to concentrate where we need: in the complexity of our system, not in the ‘housekeeping’ of it. We are paid to develop valuable software, not to spend time deciding where this or that file must be.
So, my advice is “Do NOT change conventions without good reason”. And I mean a REALLY good reason.
Going back to the tables stuff… One may change the name of a table associated with a model using set_table_name. But why would you do that? Let’s examine some explanations people usually give:
  • I am converting a legacy system to Rails and the table already has a different name. Great. Then rename it. Besides, if a table containing users is called ‘potatoes’, for instance, then there is some problem with the modelling of this legacy system, or with the mind of the person who named it.
  • I am converting a legacy system to Rails and the table I’m working with contains users, but also other data. Then again you have a problem in your modelling and since you are refactoring the system to convert it, it’s exactly the time to change this. You have no problem that a new table to separate this data and a foreign key won’t solve.
  • I am starting a new system from scratch, but Rails conventions are an obstacle to my creativity and I want to call the table of users by another name. You are an asshole! A big asshole! Forget programming and go to fine arts. Painting, maybe. There you may express your creativity without bothering people.

What would be the advantage of calling a list of users by another name? One of the most basic problems this would cause would be the fact that rational people (and we expect programmers are rational…) will take some time to understand your “creativity” and realize that table named ‘potatoes’ contains, in fact, a list of users. If you use this kind of “creativity” a lot, in the end your system will be a complete mess and the level of maintainability will be very low.
Rails conventions were created to make things easier. Do not change them if you can avoid the change. And if you can’t avoid the change, at least document it very well.
In my next article I’ll discuss things that may sometimes (and in fact sometimes need) to be changed.