When maintaining and improving upon legacy code it’s easy to redefine standards, or define nonexistent standards, which have cascading effects on the pipeline. Take something as simple as an ill-conceived naming convention which, in hindsight, turned out to not make sense over time. At some point the benefits of rewriting lots of code outweigh simply sticking with the bad convention. In these cases consistency over standards become the convention.

A simple example of consistency over standard

As I’ve discussed before, putting the comma separator before the field name in your queries should be the defacto standard that we should all enjoy, but what about a messy, inconsistent code base?

Let’s imagine two scenarios: One where the standard is simply reversed and to meet your new convention you’ll have to move the commas from the end to the beginning and Two where the entire query is wrought with inconsistencies.

Now imagine you’re making a very minor change to a filter condition. If you clean the code up to match your standard, both methods require significant testing due to making so many changes. What if there are other standard-violations you should also correct?

This is when implementing a standard for existing code bases requires the first standard to be consistency over standards. Rewriting a large procedure to meet the new standard could have serious effects that will cascade throughout your pipeline.

Code Review

During a code review I’ll fail a pull request that doesn’t meet the standards we’ve defined. But, before I do, I’ll double check the existing code/convention to see if it’s consistent. If our number one standard is consistency over standards then reviewing code becomes clearer.

However, leaving inconsistent code because “it was that way” is not standard nor consistent.