in reply to Re: Maintenance vs. Programming style
in thread Maintenance vs. Programming style
Bravo. I concur with every word.
The only addition I would make is that if I have to fix or modify a piece of shared ownership/corporate code that is in a style radically different from my own preferred, then I will often go through the same "re-write and rename to my style" process in order to get to know that piece of code--on a private copy.
Only once I am convinced that I understand what the code really does and it still passes any existing tests, will I attempt to fix or modify it. And once I have made and verified the changes, I'll go back to the original and attempt to re-make them, in the original style, minimizing the changed lines commensurate with doing the job right before check in.
80% (figure varies) of the life cost of a piece of code may be in the maintenance phase, but I've seen studies that put up to 50% of that 80% as backing out incorrectly fixed bugs; fixing introducd bugs; or the backing out of features added that broke existing code.
Hit & run maintenance costs. And the two primary causes are: 1) 'simple' changes made to 'simple' code that turns out not to be; 2) changes made on the basis of out-of-date comments. I suspect, but have never seen proof, that a third cause is attempting to minimise changes for the sake of VCS change history stats.