
 |
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:
- Everyone can benefit from planning.
- Only those familiar - or dare I say proficient - with the language will be able to benefit from using a debugger
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:
-
C How to Program by Deitel & Deitel
This book is a bit expensive, but it is exhasutive in it's scope. If you had to be stuck on an island and could
only pick one book to learn C, this would be it. It covers not only every actual aspect of the language,
but also touches upon C++ and in the most recent edition, Java. Examples exist for nearly every topic.
It's organized in a course-framework, and some of you may enjoy the optional exercises at the end of the chapters.
-
Data Structures and Algorithms by Aho, Hopcroft, and Ullman
With two of the three authors of the dragon book, you can pretty easily guess you've got a winner.
Oh, and you'd be right. There's many data structure books out there, and this is the only one I know that makes any sort of consistent impression.
Like all computer books, it's a little expensive, but this is actually a manual to learn from. If you can do without a genteel guide, almost every
book out there with the name "Data structures in C" will work for you; though many are nothing more than encyclopedic reference manuals.
-
Introduction to Algorithms by Cormen, Leiserson, and Rivest
One of the many Bibles you'll see bandied about. This includes searching, sorting, data structures, graph theory, number theory, and
NP- Completeness. This is not a book to learn from. This is a reference book with VERY small type. Algorithms are given in shorthand.
Implementation is left to the reader. That'd be you. Still, it's a bible for a reason, and it's not just the high price.
-
Advanced Programming in the UNIX Environment by Stevens
Another Bible. This one is a rather encyclopediac reference to the Unix system fundamentals. Like most bibles; invaluable information, often inscrutable
format. As above, you'll need to put in a bit of elbow grease, but lucky for us, Stevens gives examples in C code. Not a bad book in any way.
-
Interprocess Communications in Unix : The Nooks and Crannies by Grey
This book covers roughly the same material as above, however it delivers it in a friendly fashion. This book presents many
useful and otherwise unused features of the Unix systems, as well as being a good introductory guide to network programming.
If you've ever thought "I should just rewrite this MUD from scratch, but I don't know how to do the network crap," this is your first
book into the wide world of network programming.
-
Internetworking with TCP/IP Vol. III Client-Server Programming and Applications-Windows Sockets Version by Comer, Stevens
There are alot of you out there stuck on the windows format, and the above books - while useful - do not provide the instruction
a windows network programmer needs to start out. This book covers all those bases, and what sold me on it - there's a nearly
identical version of this book themed for unix systems. Makes learning one system easy if you already know the other, just put
em side by side and compare and contrast. That book can be found here or linux specific version, here
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.

