Sponsored By
Michael Carr-Robb-John, Blogger

February 22, 2011

3 Min Read

Sooner or later it happens to us all, for one reason or another we take a look back through old code we wrote years ago. In my case, I was actually looking for a class that I thought I could re-use in another project.  While hunting around I happen to come across a comment that caught my eye:

    // This is a nasty Hack, re-write me.

Obviously the hack wasn’t that bad the project had shipped, but it did make me wonder a little. A quick find in files revealed that the word “Hack” appeared 217 times and not just ordinary hack’s either there were “Giant Hacks”, “Uber Hack”, “Dirty Hack”, “The Best Hack”, “@hack”, “A bit of a hack”, “Minor Hack”, “Hacky”, “A Little Hack”, “Nasty Hack”, “Hack Hack Hack”, “Clever Hack” and just a single lonesome “Hackers Delight”.

Hmmm, a few more find in files later, revealed the following:

                                   Number of instances

   Hack                                    217

   To do                                    52

   Fix {this, me}                       37

   Various swearing                472

So what can this tell me about the code?

Maybe that there were 89 tasks that were never managed in the project’s schedule / task list, that a total of 217 hacks were implemented because it was easier at the time than doing it properly. That programmer’s like to swear and rant silently in their code.

I could have left it there, but my curiosity got the better of me. I dug a little deeper looking at each Hack, To do and Fix comment and asked myself the question was it relevant, was the code really hacked? Had we shipped a title with things that still needed to be fixed, were the “To do” jobs really missing functionality.

                                Number         Applicable

   Hack                         217                27

   To do                        52                  3

   Fix {this, me}           37                  0

My results were a little more palatable, there were at least 3 tasks that had been marked to be done that should have been done (In my opinion). It’s possible they were waivered as not important enough to warrant implementing, it’s also possible they were marked in the code base to be done but never actually got put onto the task list of work.

These thoughts have confirmed how important it is to have a general maintenance task that should be scheduled every couple of months during development to call out the hacks and To do’s to make sure that they don’t get forgotten about.

As for the swearing, I am guilty of writing the occasional nonsense comment in the code from time to time, mainly for entertainment purposes for my fellow engineers (We write games after all). But I do not use foul language and actively discourage the habit in others it’s unprofessional, as plain and as simple as that. Most Engineers are highly intelligent creative people, so let’s come up with something more creative.

Read more about:

2011Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like