So it isn’t very often that I blog about programming. In fact I don’t know that I have ever done it before, which is kind of strange since I spend a huge amount of my life doing it, but this is a moment that I feel the need.

I just lost a ton of time due to some dead, unused, and generally crappy code. I was working with a class that had a private reset method (and it was called), that should set off alarm bells, why would a class need to reset itself. As well this manager class owned a single instance of a ‘handler’ class. If it has a single instance of a handler, why does it need a manager. What made this worse was that handlers were handed out and returned from a pool of handlers. Ughhh. It was terrible.

Ok so I spend a few days untangling things so I can make some changes. I was able to get rid of the reset functions, the class was never reset, new instances were created. I was able to take out the handler pooling, a new handler was created not taken from a pool.

So it was painful to fix, but the part that really set me off while working on fixing this stuff was when I removed the pooling I got to a comment that was something along the lines of:

//TODO: implement pooling

I wasted tons of time just to find out that there was no pooling, and that there was a new instance created everytime, and that the idea of reseting a handler wasn’t needed (even though it was done). This brings me to my next point: NEVER LEAVE TODOs IN YOUR CODE! I know you have done it, I have done it, but it shouldn’t be done. In the code is not a place for a TODO, the code should appear to do exactly what it does, nothing more and nothing less. Leaving a TODO like: //finish the implementation of this class because I am a lazy and useless programmer does nothing to help anyone, it is just a time waster for a future programmer.

If a bit of code will someday be used to cure cancer, don’t put in a function called cureCancer() that does nothing and has a //TODO: cure cancer comment. That just makes it look like it does something it doesn’t. If it needs to cure cure cancer in the future, document that in the backlog, provide notes, provide sample code. But! Whatever you do, do not make the code look like it will cure cancer.

Share This