in reply to Maintenance vs. Programming style

As most posters here agree, if $work imposes standard style and coding practice, follow that! If I find colleage-code that doesn't follow these rules, I fix it and remind that person about the style we agreed and why. <rant>It cannot be denied that some people care less about small things like indentation and whitespace use than others</rant>.

If I get a project as a new and only owner, the very first thing I do is rewrite every single line to adhere to my style. Not only will the new code be very consistent and beautifull layed out in my perception, but it has proven a great way to understand what the original author had meant with the code in the first place. By reformatting, renaming, and reordering, you get a very good grip on the complete project and you can add the comments of your findings while you are at it, giving the next maintainer (in case you die) an even better base to start from.

Once style issues are `fixed', and of course all tests still pass, the first thing to do then is to put the project in git (fill in your favourite VCS) and find open/outstanding bugs. Now you understand the code, and have no excuse about not able to read it, fixing those should be easy^Wless difficult. Add tests for all the things that were unclear on this journey through code and for all the shiny new features you just added and release it.

Enjoy, Have FUN! H.Merijn

Replies are listed 'Best First'.
Re^2: Maintenance vs. Programming style
by BrowserUk (Pope) on Jan 29, 2008 at 12:41 UTC

    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.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.