Freedom and order

In software, understanding what the code does is crucial.
When you write a piece of code, you know what it is supposed to do, why has it been written this way, and how it is supposed to be adapted, if the things around would change.
You have everything in your head.

When you work with other people, sometimes separated not only by space, but also by time (ever inherited a project after its creators have left the company a few months before?), sharing the understanding of the software becomes a problem.

That’s where conventions come to the rescue.

Ruby on Rails has many of them.

You know what a controller is, where it is located, where are its views, what are models, where to look for tests, etc.
Knowing the conventions (and trusting that the project adheres to them) you may skip a lot of otherwise necessary checks. You may assume the `GET /api/v2/makes/de_lorean` call will be handled by the `show` method defined in `app/controllers/api/v2/makes_controller.rb`.
If you see a line saying just `make.save`, you become alarmed that the code may ignore save failure. If you see `make.save!` you feel safe.

It does not matter when or who has written that code. Conventions save you a lot of time.

Guardian

Chances are high that your team uses rubocop.

If you integrate this tool into you process, you will be warned when you use `Model.update_all` or `Time.now`. You will be warned that you have unused variable, or an unused parameter to your function — most probably because you have mistyped it in the function’s body.

But this guy has also his dark side.

Is it the right problem?

You have just finished writing The Big Thing. Several classes, clever algorithm, ideal data design, every piece works, works fast, and is rock solid. You raise your eyes, and notice the office to be empty, just as your coffee mug. Behind the window you see the Moon smiling at you.

You have run your tests many times, you know everything is perfect. You push your changes.

Offenses detected. “Line too long”, “Method has too many lines”, “Use % instead …”, “%Q should be delimited …”, “Indent the right brace …”

Few may be reasonable, but unless you have started coding just a few months ago, you may have slightly different ideas about readability. After all, your habits may have been formed by experiencing coding style by Kernighan & Ritchie, then playing with GNU or NASA standards, writing PERL or Lisp, or by years of browsing the sources of ActiveRecord and other Rails’ libraries…

Now you can try to talk with your team about the rules, or — because it’s late, and you really need to go home and have some sleep — just fix the %^&^% thing.
Your future days may be full of “smile, commit, curse, git commit -m ‘&^%$ rubocop :(‘“ until you get into habit of writing how it wants.
Part of your brain will be constantly occupied by “shall I put a space here?”, “does it want me to indent to this or that column?”.

Now imagine that the default setting of some cop will change. You will have to stop doing what you are doing, change the yesterday-perfect-today-offensive code, merge, solve conflicts… This costs your time and energy.

You may try to convince yourself that it’s for the good of the other programmers. But if they are worth their salt, do you really believe they would not recognize a string quoted differently?
Or would they care whether you use `%Q()` or `%Q[]`?

Improve

We, as well as many other good things, have been created by evolution. How would we look if Nature would have adopted “cell formatting style guide”? How would we look if the tribe chief would stop some guy from playing with new forms of cutting flint tools?

To find new, better ways, you must have freedom to experiment.

As for the code, I always (after gaining enough life experience, that is) try to apply one rule to either mentoring or code reviews:

“If the code works, and if you will be there to fix any problems with it, then it’s good.”

If you let yourself and your friends make mistakes (except ones causing the production system to break, of course), if you respect their habits, and do not force “the only right way” upon them, you may discover that maybe your years-old habits may be improved. And you will change them happily, because that will be your free and conscious decision. You will curse less, and smile more often.

If your ways are good, people around you will notice that. You do not need to hardcode it in rubocop.

Not that long ago I was working in a team, where we had a rubocop config file, but we also had a rule, that whenever any of its “offenses” did not seem right to any of us, everyone was free to disable that given check. The only requirement was to also add a comment explaining the reason, so that anyone could later question and discuss it, if needed.

And that is what I would suggest you. Do not just adopt laws (or style guides) coming from some powers above. Question them. Respect the freedom of all people around you, learn from mistakes, adopt good things.

See also:

- http://relaxed.ruby.style/