Thursday, August 16, 2007

Code masters

Now I like coding as much as the next man - the next man being someone who quite likes his coding - but there's one aspect that can be especially infuriating: debugging.

Writing a nice piece of software from scratch can be quite enjoyable and even a creative process (programming is an art form!). You think about what you want the program to do and work out how to best split the task into seperate managable functions and structures; then you let the creativity flow down your fingertips, through the keyboards and onto the text editor of choice (I use kwrite, which many might think is a bit of a soft option and I should instead be using something more hardcore like emacs, xemacs or vim instead, but I like kwrite goddamn it) adding your own style and artistic flourishes to your work. If you're programming in C this artistic process includes blindly declaring pointers, chanting some voodoo incantations, and hoping the thing compiles (or at least that's how I deal with them!)

Now once your coding materpiece has been completed the man steps in with his rules and regulations trying to make you conform. He throws about syntax error's here and request for member `X' in something not a structure or union's there. Sometimes your most bold and inspired brush strokes are just too far out there for the current establishment to deal with. However you deal with his requests grudgingly, but never let you artistic integrity slip. Often you find that the man's requests make you see more beauty in your work and make you appreciate certain parts of it more. This is the easy part of debugging.

Then you try and run your code - my arty analogy kind of breaks down slightly here as I've not heard of people trying to run a sculpture or painting. Segmentation fault it says. Or the output some indecipherable goobledegook, or just plain smack-me-in-the-face stupid. You respond with a swift "Bugger!" knowing that somewhere your magnum opus (arty again) is trying to access a bit of memory that's not been allocated, or is plucking random numbers out of thin air (aka somewhere in the computer's RAM). This is followed by adding printf statesments just about everywhere to work out where the program's falling down. When this doesn't highlight the problem and you can't see anything at all that looks wrong you start banging your head against a brick wall for several hours/days/weeks/months getting more and more irrate and frustrated! Your urge to kill will rise to quite extreme levels (did you know that there is a large statistical blip in the murder rates around Redmond, WA!) More often that not after an undefined period you realise that you've been excessively stupid, fix a minor unseen, but blindingly-obvious-when-you-spot-it, problem, and everything works out well. Although sometimes codes are just tempermental beasts that work one day, but not the next!

Anyway I suppose it's best that a piece of software falls down completely at the start rather than working properly, producing reasonable results, and looking hunky-dory, for ages before you realise that there's a mistake. But that never happens now does it...


  1. gdb is, most definitely, your friend.

    Compile with as many -W flags as you can find turned on. Compile with -g to enable debugging flags.

    Run your binary through gdb; easiest way to work is to run, then obtain a backtrace when something fails. And hope that you're not dealing with a bug that the gdb environment magically does away with.

    gdb takes a bit (!) of learning, but it's astoundingly powerful piece of kit.

  2. Yeah, I know I should really learn to use gdb. Maybe someday...