Cléber Zavadniak Website

Don’t be consistent with shit

When dealing with legacy code it’s reasonably common to face some weird reasoning during code reviews, like appealing to the argument of consistency even when that means being consistently keeping the code a giant mess. And then, instead of slowly fixing the code base the developers keep slowly worsening it as if being consistent was a value by itself that makes it worth the problem.

Flowers

But it’s not. Don’t be consistent with shit! If every file of the 1.5 million LOC project import modules using the wrong syntax, do not hesitate to make things right in your new files. Consistency is only valuable when your code is consistently good. It’s better to have a project that is not consistent and made of, let’s say, 15% good code than a code base perfectly consistent and made of 100% bad code.

Things are bound to change sometime and it’s very unlikely that will come a day when the team says “hey, we should stop delivering new features to fix old code” – that’s not going to happen. So the only chance you have to make things better is… well… making things better.

Now, I have two tips:

  1. Every new code should be excellent;
  2. Old code should be fixed in a separate commit.

If your team is mixing up features and code refactoring, the code review process is going to be confusing, tiresome and time-consuming unnecessarily. Whenever you need to refactor some old files, do that first, open a new Pull/Merge Request, and then start working in the next commit that is the feature itself. Your colleagues will thank you for that.


Back to index