Tiny Frog Software

Yesterday I spent the entire day refactoring code for my upcoming game.

Refactoring is a funny thing because essentially you have to break your code, rearrange it, clean it up, put it back togeather, test it, and then hunt down all of the new bugs you’ve introduced into the system – By which time you should end up with a program that resembles exactly the same program you had before.

And your line count doesnt even go up.

However, I do think its very important to do refactoring as you go and I’m going to try to spend one day a week where instead of writing new functionality I’m going to take a look at the existing codebase and try tidy it up. This will hopefully reduce the probablity of errors popping up as any assumptions I made to get something ‘to just work for now’ will be removed.

The other goal is to start to make the code more re-usable and not so specific to my current project.

Meaning I can reuse code for the next game I work on. The obvious target for this is the GUI library and Finite State Machine code which is turning out just peachy. Of course one should be very careful – I’m working on a game, not a gui library. Which is an important distinction to keep in mind. And although it’s my opinon that its a good idea to refactor, one should only do what is necessary.

One of the principal reasons for the refactoring yesterday was because I need to implement modal dialog boxes and the way the GUI library was structured it would have been a very nasty hack™ – In my case refactoring was nessesary in order to move forward – what Jay from Rampant Games calls a Local Maxima Problem.

I haven’t read any technical books on refactoring code. But I’m going to add a few to my reading list and perhaps sprinkle a few tidbits about how to improve code as you go in a later blog post.