Home > Misc. > Debugging: Get good at it!

Debugging: Get good at it!

You know, the only thing more satisfying than having a bunch of code work the first time you program it, is FINALLY finding that bug that’s been haunting you during six hours of debugging. The debugging sucks (having to set up debug messages/logs, breakpoints, etc.) but as much as I’d rather not have to debug, I’m not that worried about bugs in general because due to all my experience I know that I’m good at debugging.


No, this blog post isn’t just to brag about the fact that I’m good at debugging (nor is it about monkeys, though that would be very cool), but rather to make an important point: Learning to debug is an EXTREMELY important skill for every programmer, and it is NOT the same as being “good” at programming. Debugging, in my opinion, is a logical process separate from the ability to write code and fix problems, and if you can’t debug, then you’ll likely never finish any project except by luck (i.e. not ever typing a bug in the first place); or at the very least, it’ll take you a very long time.

Remember that since you’re writing code, the problem, if there is one, is due to something you typed. It’s gotta be somewhere in that code, but WHERE? Where do you look for a bug if you just wrote a couple hundred lines of code? And more importantly, how do you figure this out?

Ideally programmers shouldn’t be writing that much code without intermittent testing, but there are many times in which some parts of code can’t be tested before writing hundreds of lines because the first 100 lines are useless without the last 100. So if you’re in that situation, where you’ve got a whole bunch of newly tested code (which ends up bugged), do you really have to go through every single line to find where the bug may be?

No, and that generally wouldn’t work anyways. How many times have you been working on a math problem and it just isn’t working out, so you know there’s a problem somewhere but you can’t find it? Most of the time, it ends up being the case that some operation you performed was wrong but you kept telling yourself it was right because that’s what you had been telling yourself since you first typed it. Recently, in an iPhone project, the board game I was programming didn’t work right simply because I typed “gameBoard” instead of “newGameBoard”. I won’t go into specifics, but needless to say it took me a while to actually SEE that problem because for a long time I didn’t know the general location of the problem.

So in general, with any sort of code, one must be able to use programming skills to know what to write in the first place, but DEBUGGING skills to logically deduce where the problem is. For example, say you have three lines of code in question. Commenting out any one of the lines doesn’t help, but commenting out lines 1 and 3 at the same time fix the problem. Commenting out line 2 has no effect. What do you deduce?

Hopefully you figured out that lines 1 and 3 must have something in common. That being the case, you should look for that commonality (perhaps a variable/object pointer or some function/method) and find out what might be wrong with it. We can see here that this alone did NOT require any programming knowledge (except perhaps some basics like what “commenting out” means and what variables and methods are), just some basic logic.

But usually we’re not so lucky to have the problem narrowed down to just a few lines for us, so how do you do so? You need to use your debugging skills and techniques. For example, one might use log/debug messages. They’re extremely helpful because they allow you to SEE what’s happening in your code even when it doesn’t change anything visually in regards to the game/application window. By placing debug messages at strategic points, you can see things like how many times a for loop has iterated (by seeing how many times a particular message is displayed) or whether a freeze occurs before or after a certain point in the code (by seeing which messages are displayed and which aren’t). Debug messages are also useful for viewing variables and especially the contents of arrays when necessary; the possibilities are endless, and they help dramatically narrow down the amount of code you as the programmer will have to sift through when looking for a bug.

But again, no matter how good you are at programming, you’re still going to need to separately learn how to debug. Logging may again take some basic knowledge of programming, such as how a compiler/interpreter reads code, but its use in debugging is pure logic. If I put a log command here, and it doesn’t show up before freezing, the problem must be before this line. If I put another log command ten lines before the first one, and the next time I run I see the earlier log message but not the later, I know the freeze is between the two log messages. If I see the earlier log message over and over and over again repeatedly, I know the problem is some sort of infinite loop or recursion. Hopefully you get the point.

Debugging isn’t the process of fixing bugs; that is programming. Debugging is the process of identifying bugs so they can be fixed. And again, one must learn the two separately. Many programmers do learn both at the same time, but it’s because they hopefully go hand in hand. Others don’t use debugging skills, struggling to read through each line of their code just to identify a typo, sometimes taking days or weeks to squash the simplest of bugs. If you are one of the programmers who suffers from the inability to quickly identify the location of bugs, start reading up on ways to make it easier on yourself. Start learning how to debug.

If you want a head start, you can try my post about debugging with Game Maker, because even though it was written with Game Maker in mind (which I don’t write about any more) it’s concepts are valid almost anywhere. Good luck, and be sure to let me know what you think about debugging, too.

Categories: Misc.
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: