Some of my fondest memories from childhood are the times my dad let me tag along on his weekly trips across the expanses of Northern Ontario in his 18-wheeler. As you might imagine, a daily ritual on these trips was one of washing up in some dingy restroom1 before eating a greasy breakfast (“two eggs sunnyside up, bacon soft, rye toast please”).
All these years later, the biggest lesson that stuck with me was “leave it better than you found it.” In other words, not only “clean up after yourself,” but also “clean up the mess you found.2” After all, the next guy’s going to appreciate a clean space to start his day.
Old code is like a dirty truck stop restroom.
As part of working on code guidelines for my day job, I read a bunch of the code standards and adjacent posts. None of the documentation, blog posts and idioms (DRY, KISS, etc) really touch on legacy code. I suppose it makes sense since they are generally aspirational documents. At the same time, I think these documents are incomplete without touching on it.
As programming languages and platforms mature and fads of the moment fad away, it’s becoming more and more common for developers to run into old code. Maybe even code that’s predates code standards in a given language. This is certainly the case in my day-to-day.
While it’s relatively straightforward to install IDE tools to format you code properly and keeping it simple can be easy when you don’t have to consider a decade of backwards compatibility. It’s less obvious when you’re not working with a clean slate. What do you do when you encounter ugly code? What about when repeating yourself it the shortest path to a complex fix? Should you re-write an entire library because doesn’t hold up to code standards?
I propose adding LIBTYFI3 to the lexicon of idioms.
If the code is ugly and misformated. Fix it4.
If you’re repeating yourself or having trouble keeping it simple. Step back and assess what you should actually be refactoring. You’ll probably learn something about the application in the process.
If variable and functions are named poorly. Fix them.
If comments are missing. Add them!
If tests are missing. Add them.
In other word, if code is not holding up to current standards, rewrite as much as possible as long as it’s tangentially relevant to your task.
Obviously this is going to take more time than a quick fix. Perhaps, if your task is truly a critical fix you should skip some of these steps. But stakeholder should understand that legacy projects are complex and taking time to do it right will lead to a better product in the long run.
1 – Lest you question my Dad’s parenting choices, I can assure you small town Northern Ontario truck stop restrooms in the 80s/90s were not nearly as sketchy as the image you probably have in your head from movies and TV.
2 – This rule did not apply to toilets.
3 – Libby-fi? Sounds like some poorly thought out Liberal social network.
4 – But please for the love of god, isolate style from functional fixes in their own PRs.