Maintaining old code is what I do at work most of the time. If there is a new feature to be added to the product, there will still be a large amount of existing code that needs to be waded through to get to the places where the new feature will become integrated. here are some good rules that I follow that I and others seem to ignore:
Don’t use single letter variable names
I HATE working on code that was written by someone who knew what the code did because it was all in their head. You don’t need to give a better name to “Q” if you know that “Q” is the ratio between the incoming data rate and the outgoing dollar-per-minute burn rate of the generator running the facility. I do. I need to know what the hell “Q” is because I don’t have your stupid source code memorized.
Why do I mention this? Because my own source code from ten years ago keeps rearing its ugly head and causing me problems. Sure, I can figure out what “Q” is but I’d rather it have a name like “DataToGeneratorRatio”. it’s just much easier to understand things that way.
Use English if you are using english
How about using the variable name “Cntr” instead of “Counter”? No. Don’t do it. What it saves you in typing time is lost later when you need to write documentation and you can’t use the keyboard or spell real English words. If you’re German, use German. Just don’t use That vowel-less nerd language. If you learn to touch type and use real words, you will end up being faster than if you try to leave out the vowels.
That word is strange to me. Just fix the code to work right and to be optimal and clean once it is working. Don’t leave it in a “works as-is” state. Write it again in a clean and understandable way.
I do this refactoring constantly because each time I touch my own ten year old code, I find another area where I took a short cut that is now causing a problem. The most important things to me when refactoring code is to remove redundancy and to break the code up into smaller functions. If there are three operations in a row that each take 20 lines of code, put each in a function and have the code that calls them just have three well names functions to call. it seems to make things much easier to maintain because it makes the code smaller and more self-documented. You could add comments to each of the 20 lines of code and leave them in place but it is still 60 lines of commented code instead of three lines of code. Each section is then treated separately and can be worked on without the other stuff being a distraction. Worse, one section of 20 lines of code may become dependent on another 20 lines of code and then there is no way to reuse some of it or move it around to be more optimal.
That’s all of the venting for today.