Is It Bad Code, Or Just A Different Programming Style?

Ever find yourself working late into the night, working to maintain code that somebody else developed, and wishing kidney stones on the original developer for creating such a wicked, convoluted mess of code?  Yeah, we all have.  However, is it always fair for us to curse the original developer?  Perhaps before we wish any painful afflictions on them (and I hear that kidney stones really hurt!), we should take a step back and decide whether we are dealing with truly bad code, or just a different programming style.

Here is a quick little guide I use to decide whether or not I need to pull out the voodoo dolls.

This list is obvisouly not all inclusive.  In fact, if any readers can think of more examples, please feel free to leave them as a comment.  The point is that sometimes we become frustrated when we maintain other people’s code because the solution was implemented differently than the way we would have done it.  That doesn’t necessarily mean that it is bad code.  When we encounter code like this, it is important to take a step back and look at the code objectively.  Ask yourself questions.  Why did he use a delegate here?  Why did she move these utilities into a single class?  Why would they choose to use one design pattern over another?

Instead of complaining about the original developer, this could be a good opportunity to learn new programming techniques or reinforce the ones you currently use.  Unless it truly is bad code.  Then by all means, wish for kidney stones.