RuboCop in legacy projects, part 2: Focus on the present

Applying your style guide selectively is the way to stay sane, but takes a little work

Photo by Kevin Ku on Unsplash

TL;DR Relax about the state of your old code (for now); work out how to make your new code (including changes) conform to your style first.

In my previous blog post in this series, I took a look at setting up RuboCop for use in a long-term legacy Rails project, including how to best utilise the ability to autogenerate a TODO file.

In short, contrary to what the --auto-gen-config option does for us, we shouldn’t inherit from the generated .rubocop_todo.yml file. That leaves our main configuration file, .rubocop.yml a lot cleaner. To repeat from that last post:

.rubocop.yml is a definitive statement of how we want all our future code — whether brand new, or rewrites of older code — to be written.

But if we have a clean, definitive config file, running rubocop on the command line will most likely throw out a vast number of violations to be addressed.

The sheer quantity of those can feel overwhelming. I think that’s possibly the major emotional reason why people like the ‘traditional’ way of using .rubocop_todo.yml to get to an ‘all green’ state, to falsely assuage the guilt of seeing…