Code Quality

I generally believe that code should be easier to read than to write. There aren't many exceptions to this and hard-to-read code is often a signifier that a brief code review might be in order.

Tonight I discovered a class that doesn't do what it says on the tin, so didn't do what I expected it to do and had two responsibilities so boot. So its been split in two, and each half aptly named. In retrospect its a lot of typing and when you finally run the game its *exactly the same* but that's kind of the point of this kind of refactoring. Its made adding new stuff easier and what I've got is easier to read for future revisions.

The clean-up has exposed a juxtaposition of bad habits, itself a more interesting point than the code or class layout in question. The contents of the class was place holder and had been overlooked for quality because it was "only temporary". Another symptom of being left to rot was the suspicious 'todo' comment that had never been followed up.

The experience has highlighted a serious difference between a naive implementation and bad code. Knowing that I was writing an implementation that was going to be thrown away meant I'd turned a blind-eye to a poor choice of interface, and that's where the rot started.

The old lesson relearned... there is NO SUCH THING as throwaway code. As you write, you just don't know how many weeks, months, or years a temporary class is going to last. I could just have easily have looked at it, saw it was ugly and left it alone. Or compounded the problem by just hacking my new code in. But the clean-up has left me with more functionality, less code and more readable, intuitive classes with shallower inheritance.