Ugly Coders Word of the Day: Refactoring

If anyone was wondering why I would call my site code ugly, it is for a good reason. I write ugly code. At least the first go around. So I thought I might write a semi educational look on ugly coding and refactoring. It's what I do, maybe you should try it. OK, here goes.

(Disclaimer: This is general, so I statedclasses instead of torque data blocks)

It takes me a while to really get comfortable with a language. For a while I am nose in the manual on every line, then I slowly move into writing my own errors without the help of a manual. I just keep stubbornly hammering away knowing that on some far off sunny day things are going to make sense. And that, is precisely when things get nasty. :-)

It is at this point that I start going over old code looking for functions and frameworks that I set up and I realize how poorly implemented they are. One thing I, and surely many others, fall into is implementing quick code to get something working. Especially when working with a new element of the language. So as this piece of code gains more functionality it becomes much harder to maintain. There was a point where I would try to avoid doing this at all costs, and wound up wasting more time than I saved. So now I embrace the ugly code as a productive tool, which brings us to refactoring.

When I implemented a combat system in my game, I originally just stuck a few functions with lots of logical sorting to decide what stats determine what sort of attacks and so forth. It worked great while I was just using damage options. It even worked a little smooth when I added the ability to heal. Things, however, got really tricky when I started trying to add stuff like status effects and other odds and ends of a fairly standard RPG. Rather than nesting the function, I shrunk the function down to making one external function call to the specified attacks class method.

On a flip side, there is a bit more code work to do with this structure. However, maintaining and extending the code is much simpler. What I usually do is try to part out the code to functions that I know will be used in multiple classes. Sometimes it takes a few runs to make sure I am passing enough data into the functions for all the work that needs to take place. Finally, before I know it, my code is not as ugly as it used to be, and when I decide at the 11^th hour that monks should be able to meditate in the middle of combat, all I have to do is create a class and over ride a method call.

Hopefully this has lifted the self esteem of other ugly coders out there. Yes we write ugly code, yes our functions are in excess of 1000 lines long, and yes, we skipped our own prom to go fishing. But we are coders too saying, fewer function calls equals more optimal performance ... er ... I mean ... our code can refactor into something a little more ... yeah ... more. :-)