Should older code be updated to use newer language constructs, or should outdated constructs be stuck with

maintenanceprogramming practices

I want to make some enhancements in some still-functional code that was written a long time ago, before the programming language it is written in grew in features. In theory, the whole project uses the up-to-date version of the language; however, this particular module (and in fact, many other modules) are still written in the older dialect.

Should I:

  • Not touch the parts of the code I don’t have to touch, but write my patch making use of the new language features that make it easier to write the patch but are not used in analogous situations anywhere else in the module? (This is the solution I’d intuitively choose.)
  • Ignore the fact that years have passed, and reflect the style that is used in the rest of the code while writing my patch , effectively behaving as if I were doing the same task many years earlier? (This solution I’d intuitively consider silly, but given the amount of fuss everyone who speaks about “good code” makes about keeping consistency at all costs, perhaps this is what I should do.)
  • Update the whole module to use the newer language constructs and conventions? (This is probably the best solution, but might require lots of time & energy that could better be spent on a different task.)

Best Answer

It is impossible to give a definitive answer to this question, because it depends too much on the particulars of the situation.

Consistency in style of the codebase is important because it helps in making the code easier to understand, which is one of the most important aspects of maintainability.
You wouldn't be the first programmer who got cursed to hell for making the code hard to understand by mixing different styles. It might even be yourself that does the cursing in a years time.

On the other hand, using new language constructs that didn't exist when the code was first written does not automatically imply that you are reducing maintainability or even that you are breaking the style of the code. That all depends on the particular language features you want to use and how familiar the team is with both the old style of the code and the new features.

As an example, it would generally not be advisable to start introducing functional programming concepts like map/reduce to a codebase that is completely in OO style, but it could work to add a lambda function here and there to a program that didn't use anything like that before.

Related Topic