Something, something, … Refactor!

by Koen Metsu

Many of us developers leave for work on a daily basis, ready to throw ourselves onto the next change request that will change the world as we know it, only to find yourself hack ‘n’ slashing through a jungle of WTF’s, copy-paste inheritance, awfully named fields, and more WTF’s.

This probably sounds like a broken record to you, and though I could go on all day presenting you with examples, I’d rather suggest an alternative: Refactoring.

Refactoring is a word mostly spoken in the domain of TDD, from its well known mantra “Red - Green - Refactor”.  However, refactoring does not belong exclusively to the exotic world of TDD, which can spark fear in the minds of many developers not familiar with TDD.

Refactoring has been the topic of many books, and rightfully so. The list of possible refactorings is a long one, but many of these techniques are really quite simple.
And more importantly: it can significantly improve your code base.

Yes, refactoring can improve readability and flexibility, which in turn improves maintainability. Improved maintainability leads to less money spent on fixing bugs, which leads to happy customers, which leads to less picking on us poor developers, a more satisfying job and ultimately: improved health by reduced stress. See that? All benefits! =)

When done, refactor

So why do we write less readable, less flexible code than we possibly can?

With deadlines and project managers breathing down our neck, it is easy to conveniently forget the refactoring part and move on to the next task at hand. We hope to never see that piece of code again, or think that the code we just wrote is “pretty ok enough" to understand 6 months down the line ( hint: it isn’t ).

So when you’re leaving the campground, be sure to leave it cleaner than you found it, and clean up after yourself. Start off by asking yourself the following simple questions:

  • Could my field names be any more meaningful?
  • Are my method names truthful? ( ie: don’t lie )
  • Do I repeat myself unnecessarily?
  • Does my code need any documentation? ( answer = yes )
  • Do I still need that piece of commented code? ( answer = no )
  • Could any other developer read this code and on sight understand what it does?

Contemplating about these things alone can be the first step towards a cleaner codebase and a happier life in code, knowing you’ve become a better developer. Next time you have to change something in that particular code file, you will thank yourself you took 5 minutes to clean up.

So while you’re at it, why not also improve your codebase with:

  • Checking if your code is SOLID
  • Programming to interfaces instead of     implementations?
  • Writing meaningful tests?

There are so many other things you can do to improve your code. Keep reading about ways to code better, and remember to refactor and clean up your code whenever you’re done with a little piece of code.

ConclusionEven if you won’t have to maintain your code in the future ( never say never ), clean up your code when you're done with it, even if it's just for good programmer’s Karma and the next guy that might have to maintain it.

Stay realistic: your code will never be perfect. But writing bad, cluttered or unreadable code willingly or knowingly should never be an option, and since you have read this post, you now no longer have any excuse. ;-)