The right kind of consistency

Code consistency seems like a straightforward topic.  And it is, when you consider just the code.  But you have to consider the team behind the code and the long term evolution of the codebase.  The best architects will enforce consistency in the right area at the right time.

The ‘time’ aspect is particularly important.  Consistency at the current instant in time is important.  The team as a whole should be of a consistent mind with those things that are agreed to be consistent.  But what is ultimately a huge negative is consistency over a long period of time.

This problem manifests itself from minor to major consistency issues.  On the minor end, let’s say you prefix all members with ‘m_’.  You realize later than ‘_’ is shorter and much easier to type.  Why not just switch over to ‘_’, if your team agrees it is better (and who wouldn’t?).  If everyone agrees, then you don’t have to worry about ‘competing styles’, as often happens if you don’t have a uniform style.  You’ll have more code edits as you change over styles, sure- but these are minor and trivial edits (and very easy to diff/resolve/merge, if that’s what you’re worried about).

On the more major end, you have something like not allowing early returns.  Again, there’s no reason to enforce this rule for the sake of consistency- debugging with early/multiple returns is no harder.  What is clear, though, is coding with less nesting is a benefit (nesting increases the cognitive burden placed on the reader since a single line of code seems actively dependent on more states- there’s good writing about this if you want to investigate).  But mostly, having one return in a method is another outdated C++ leftover.  So why sacrifice all new code because the old code, conceived in a more ignorant time, is inefficient?  Break consistency to move forward.

And that’s the key to the whole thing.  Consistency can stand in the way of progress. If current conventions are tenuous, don’t be opposed to changing them for the sake of consistency.  It is the consistency of the team and not the consistency of the codebase that matters. Otherwise, you end up only evaluating and improving conventions every several years, instead of every several months.  More rapid convention changes means you have more changes and chances to see what works and what doesn’t, find new things out, and move your codebase and team forward, inch by inch.