Time for fall (code) cleaning

Handy tips for cleaning out that old or inherited code base

082212_code cleaning_small.jpgITworld/Phil Johnson

Fall is right around the corner, which means so is fall cleaning (or, for you folks down under, spring and spring cleaning). What better time to clean out that closet and ditch those man-Uggs you never wear (what were you thinking?) and, while you’re at it, spruce up that old or inherited code base?

Or should you even bother cleaning up old code? Maybe it’s working just fine and you don’t want to take the time and want to leave well enough alone.

Niklas Frykholm recently wrote a great piece over on #AltDevBlogADay about cleaning up old code. He talks about whether you should bother to clean code and, if so, offers some tips and advice on how best to go about it. He makes some particularly good points, such as:

* Should you even bother? Before diving in, evaluate whether it’s worth spending the time to clean code. Sometimes it’s not, but, as he puts it:

...the long term effects of never cleaning your code can be devastating. Entropy is the code-killer.

* Use source control, particularly a system that will allow you to make and commit changes in a separate branch without harming anything.

* Make (and commit) small changes and don’t clean and fix at the same time. In case something breaks, you want to be able to easily figure out what changes caused the problem.

* Remove unnecessary functionality and most comments. Remember, thanks to source control you can always retrieve code you’ve removed if you need it later.

* Get rid of (or reduce as much as possible) shared mutable state. Global variables, objects, and megafunctions can make code difficult to understand.

Excellent points, all.

Back in my coding days, I dealt with lots and lots of inherited code, some of it quite old. However, I rarely spent much time cleaning up any of it. Why? Mainly because I never had the time. Usually, I was part of a one or two-person team responsible for building and supporting a production system and it was all we could do to keep the current system running while adding the occasional new feature.

Also, it seemed like wherever I was working and whatever system I was working on, we were always in a state of planning for a complete system rewrite and overhaul, usually on a new platform. So, taking the time to go back and refactor a code base that was (in theory) soon to be chucked, wasn’t how we wanted to spend our time. Any spare cycles were spent on trying to move to the next big thing which, of course, we rarely ever got to.

But how's about you? Any experience cleaning an old code base? Anything to add to Niklas’ advice? And, really, why did you buy those man-Uggs? I'm embarrassed for you.

ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon