The title of this blog entry refers to a Norwegian fairy tale about a man who wanted to move away from his house where a “Nisse” (house spirit, or pixie) had become a stubborn problem. But, no matter how far away the man moves, “Nissen” is always with him… like Bad Code.
Everyone takes shortcuts sometimes, and in code these shortcuts are sometimes justified in the heat of the moment, but time has a nasty habit of smoothing over the details and before you know it the “cludge” in your code is a deeply embedded and dragged around, infecting everything and becoming very, very, hard to remove. Therefore;
The key to improving your code, and probably improving your health, is to refactor, often!
That’s how you get rid of those annoying “Nisse” and move on. For us here at Polystream this is one of our founding principles; we know that the strength of our code is directly impacting the strength of our IP, so we can’t skimp on the details!
To start with; always document your code; I don’t want to go back and have to reverse engineer my own insane creations, let alone anyone else’s. I’ve heard many an argument about how “good code documents itself” and I’ve yet to see it realised.
Refactoring is a craft and it is far from just about house-keeping and making things look pretty; refactoring is about making genuine, marginal, improvements to code to reduce the running cost of maintenance, constantly improve performance, reduce the chance of bugs, and improving your own understanding of what’s going on under the hood.
If you refactor with an eye to identify and remove redundancies in particular you’ll be amazed at some of the previously undetected nasties that you’ll encounter. When, as part of refactoring, you write tests around code, in particular code you are not 100% familiar with, you’ll not just test the solidity of that code, you’ll also test your assumptions about what it does, and how. Many times code is written with “hidden behaviour” that only the originator knew about, and that go against what names in an API might suggest. Who knew that a “Load” would end up storing something in a cache, or have a hidden dependency on some component that needed to be initialised at a particular time, etc. We’ve all been there.
There was a time when refactoring C++ was a painful exercise but now there are some absolutely amazing tools out there that can help you keep your house clean. At Polystream we really like Visual Assist from WholeTomato, and ReSharper C++ and .NET from JetBrains because they just work, and ReSharperC++ has an absolutely beautiful integration with the Google test framework, which is the framework we use for unit/component level testing; you can run or debug individual tests from within the source code for example, which is incredibly useful, I highly recommend it.
So, keep refactoring, keep a clean house and keep refining your craft. And, if you’re a certified “Code Nisse”-exterminator we want to hear from you!
Follow Jarl on Twitter @psjarlo