The Science of Debugging
Chapter 1.2


1.2 How do I Debug a Program?


Some time ago, I was contacted by a new MUD owner. He had managed to set up a new version of circle, and install a few patches, but he had a little bit of trouble. He asked me for help several times, and after a while it became apparent that he not only could he not debug his code, but did not know anything about programming.

I pointed this fact out, and he replied with an amusing statement:

"Could you just send me an email on how to code and debug things? Like, just one or two paragraphs though, don't make it too long, but make sure to put in everything I'll need to know."

Just like learning to program, learning to debug is not a process that can be adequately summed up in a two paragraph email. In general though, there are three main types of debugging we're going to deal with; planning, logging, and actual debugging (with a debugger even!).

There's a fourth and fifth type that we'll just barely touch on; using run-time libraries (electric fence, garbage collection, etc), and using non-runtime code (mainly syntax) checkers (lint, purify, etc).

This is as good as a time as any to point out two important facts:

Strangly enough, many people who aren't even capable of writing code think that by simply being exposed to it, they will suddenly be able to charge ahead like some sort of modern-day Delphian prophet with all the answers. If you are one of these people, take a moment to collect yourself, and get a good book on programming C. If you can't write code, you can't write code - simple and true. If you can't write code, you have even less chance of being able to debug it. Let me strike this point home: Effectively debugging code requires a level of ability with C surpassing mere knowledge of the syntax or even day to day use!.

If you're going to be a good debugger, you're going to need to understand why and how something works, not just what you need to change to get it to compile. If you don't understand pointers and dereferencing, memory allocation or string manipulation, you're in trouble. You may be able to get by without concepts like lists, and maps, or knowledge of sorting and searching algorithms, but it will be alot easier if you learn these things first.

I'd like to recommend a few books for anyone interested in learning the C programming language, with the first two being required reading for those who are still learning:

Some of you may notice that I have not put 'the' C book in this list. I refer to none other than The C Programming Language by Kernighan and Ritchie. There's a good reason for this; the book is a poor way to learn how to program in C. Many will disagree with me here, but I feel the book is too short, gives poor examples, and speeds the reader through the entire C language without taking time to demonstrate, expound or in some cases, even explain. In most places, the concept for a given feature is shown, and the book will charge ahead with the assumption that the reader has so internalized this idea that he or she has already realized all possible outcomes. Liken this to a teacher who writes the fundamental theorem of calculus on the blackboard, and hands out the final because "The rest of calculus can pretty much be derived from this, so I've pretty much given you the answer to all the questions on the exam." (Don't laugh, some professors ARE like that!)

The authors may have invented the language, but the only thing this book excels at is being a source for discussions revolving around "the right way to do it", especially when 'it' is programming style. If you're planning to use it as a reference, that's one thing. If you're planning to use it to learn, you're only handicapping your ability to do so.



Index
1.1 What is Debugging? 2.1 What is Project Planning