Tuesday, May 13, 2008

Software Zealots

I'm setting a record for most posts to this blog in a week.....

One of the biggest team problems you'll run across is the zealotry for the One True Way. Editor wars, code format wars, process wars, ad nauseum.

I read this recently, and it encapsulates the entire view - everyone who holds a strong opinion about software details. But the key takeaway point is that it's almost never a good idea to rewrite something if the only reason is that "I don't like it the way it is"

Case in point, I was given responsibility over a process that needed a significant new feature. By and large, the code was moderately inbred, 10 years of tweaks and fixes. I made two significant refactorings before adding the feature - I changed the polarity of the flag variables - they used 0 to mean set (do X) and 1 to mean unset (don't do X), and changing them to be 1 for set and 0 for unset brought this process in line with the rest of the system; and I replaced 4-5 chunks of repeated code with an extracted method - so that I could clone it for the new feature, which did all the normal stuff, but with additional data to process.

The rest of the code I left alone, not even changing the brace style to suit my common style, because it was safer to not change working code.


Technorati Tags --
, , ,
HTTP

2 comments:

casey said...

There's much to be said for resisting the urge to make narcissistic code tweaks. However, there is the very real problem of code format consistency.

I like to get consensus on code formatting in my projects, this puts at least the style issues to rest:

"All code shall be formatted with Ctrl-Shift-F before committing" (if you're using Eclipse).

or, "run astyle with this config file", if you prefer...

Dixie Software Ninja said...

There is definitely a place for consistent code style.

However, in many workplaces, it's an uphill battle to get everyone to agree on a style (see Religious Wars). So unless I'm given controlling authority on the code, I leave my format in the methods I touch, so that there is at least consistency at the function level.