Three Steps to Unmaintainable Code

At one time or another, we've all been asked to maintain or modify someone else's code.  On those few occasions where the code is well organized and documented, we barely notice we're working.  Coding is what we love to do and we do it.

But, on occasion, we get the code written by someone who is not as skilled in practices, frameworks or methodology.  This can lead to a frustrating experience when adding a simple feature or trying to fix a bug.

We've all seen questionable code.  And we've all got ideas on what makes it really hard to maintain.  I've been refactoring and rewriting some code the past few days and found three simple steps that you too can use to write unmaintainable code.

1. Comment your code

"What?!", you ask.  You thought adding comments helped make code maintainable?  In most cases, yes, comments help.  But to make really unmaintainable code you need to comment in a specific manner.  For example:

// Overloaded method called by the Foo class.

Yes, that's a comment in some code I'm working on.  Why do you need to tell me its an overloaded method?  I can tell from looking at the other overloads of the method.  And why tell me who calls it?  That is, no doubt, useful in some cases -- but not in the comments field!  I'd appreciate knowing what the method actually does.

Let's put this into practice and write some comments that can really dazzle and confuse future programmers:

// Static method that takes an int.

This one really shines once the method has been changed to accept a string!

// Fixes bug PR-8817

Bug tracking systems last forever, right?

// Called after Foo is initialized by the Bar class.

I wonder if there's any refactoring tools that will update these comments when I refactor this method to be called at a different time or from a different location?

2. Name your booleans as "flag".

Love this one!  For bonus points, make it a public static field.  That'll really blow 'em away!  Imagine the frustration of having 8 or 10 forms to maintain with three of them having "if(Foo.flag)", "if(!Foo.flag)" or "Foo.flag = true" sprinkled throughout the code.  Priceless!

3. Statics are King!

See item #2 above.  A good mix of instance variables and static variables really help muck up the code.  Mocking code with statics is pure joy!

Ok, my rant is done.  Back to the fun...