Legacy junk code

Sometimes you get handed over some code that is just plain junk, and you have to support it because it serves some purpose.  These kind of codes are very easy to identify, bad spacing, hard coding of values instead of using parameters, very little comments …if any at all, and most importantly huge chunks of glob that are there…for no useful reason.The glob of code could be a function that was written eons ago, but then the business requirements changed and it is no longer needed. Typically in such a case, one would remove both the function and the statement calling that function. In this case, the genius decided to remove the calling statement, but leave the function cleaning for a lesser mortal to do.

I was handed over one such masterpiece earlier this year, in which all that was required was a “very small change”. By the time I scanned the code, I knew more or less that this going to come and bite my back over and over again. Usually, I can tell what a program does by just parsing the subroutines in the code (this is Perl by the way) and identify where they map to in the main subroutine. In this case, since it was so much glob, there was very little I could make out directly. Also, the code had no indication about the ticket request that came in, so there was little reference to any documentations/ discussions that might have happened between the report writer (Yes, we write business intelligence reports)  leave alone the original request itself.

So, I cleaned up as much as I could, made the modification as requested  and tested and sent the report for installation. And it has come back to me…..to be corrected again. Now, I need to look it up all over again to see where the discrepancy is. Wish my luck

Anyway, complaining doesn’t do any help, does it ?. Here are a few tips that I learnt in my software engineering class during my Masters. I try to follow them as much as feasible, so somebody who reads my code does not have to break his head against the wall and applaud my moronism (I made that up)

1) Break the code into small parts. If each module fills up more than one window screen, then it is  probably too much.

2) Comment as much as you can. Comments can really help in deciding whether you code stays for ages or gets tossed out of the window the day someone figures out what it is trying to do (if they ever do).

3) Please, please keep as much links to the related documentation as possible. What were the business requirements that this code was originally designed for? How did it change over time and most importantly why?

4) There are many more I know, I leave the rest for the readers to contribute…I know that there are tons of readers out there who write much better code than I do.

Thanks,
Atchuth.