<< Computer Networks Practicum: How to Debug

1. Copy your program first.
2. The golden rule for debuging programs:
3. Lookout for inconsistencies.
4. Beware of voodoo coding.
5. Write a test program.
6. Look for similar bugs.
7. Look for similar bugs II.
8. Understand you code.
9. If all else fails...
10. And only if all this doesn't work...
11. The absolute best way to eradicate bugs...

1. Copy your program first. Some bugs are really hard to get rid of. In fact, sometimes a little bug can drive you so crazy that, in the process of eradicating it, you destroy your entire program. Saving your program before you start debugging is the best way to ensure that a bug doesn't get the best of you.

2. The golden rule for debuging programs: Fix one bug at a time. If you know about several bugs, fix each one and test your fix before you move on to the next bug. Fixing a lot of bugs all at once without checking your work is just an invitation for even more bugs.

3. Lookout for inconsistencies. Don't mixing bit logic coding with arithmetic coding. The statement flags = FL_ACK << 8 + FL_SYN probably doesn't do what you expect it to. Always change code like that to flags = FL_ACK << 8 | FL_SYN (the logic coding) or flags = FL_ACK * 256 + FL_SYN (the arithmetic coding). Do this with every code fragment like this you encounter, even if it doesn't seem to be the bug at hand.

4. Beware of voodoo coding. Sometimes you know a bug exists, but you don't really know why. Lets say you have a variable called index, and for some reason index is always one less than you think it should be. You can do one of two things: sit there for a while and figure out why it's coming up short or just shrug, add one to index before using it, and move on. The latter method is called voodoo programming. When you start thinking "What the hell? why is index two instead of three? Well ... I'll just make it work for now and fix it later," you're slapping a Band-Aid on a potentially serious wound.

   Voodoo programming may work in the short term, but you're looking at long-term doom? if you don't understand your code enough to really get rid of a bug, that bug will come back to haunt you. It will either return in the form of yet another weird error that you can't figure out, or it'll make your code extremely hard to understand for the poor soul that has to grade you.

5. Write a test program. If a bug's appearance is inconsistent, try to write a test program that consistently demonstrates the bug. This test program will make debugging easier and you can easily test the fix (as you should).

6. Look for similar bugs. In some ways, the ability to cut and paste code is the worst thing for programmers. Often, you'll write some C code in one function and then cut and paste it into another function. And if the first function had a problem, you now have problems in two functions. I'm not saying you shouldn't cut and paste code. But bugs have a way of multiplying, so if you find one, you should look for others that are similar. (Or just make sure something works before you start creating multiple versions of it.) Misspelled variable names are the kind of thing that crops up several times in one C program. Misspell the_name as the_mane in one place, chances are you've done it someplace else, search for them.

7. Look for similar bugs II. If you find a logical bug, like swapped source and destination parameters, find all occurrences of this type and check them.

8. Understand you code. Sometimes if you just don't know where to start (anymore), look at your code line by line and ask your self "Do I really understand this line, and why it is, like it is?" If the answer is not "I understand every thing and I completely know why it is written this way!" find out the why, what and when. That is find out exactly why it is written like it is, exactly what is is doing and exactly when the code is executed, i.e., under what circumstances.

9. If all else fails... If you're sitting there, staring at a bug, and you just can't figure out what's going on (or if you can't even find the bug in the first place, but you know it's there because your program isn't working right), the best thing to do is walk away from your computer. Go read a book, take a stroll around the corner, get a tasty beverage do something, anything, but don't think about the program or the problem. This technique is called "incubation" in some circles, and it works amazingly well. After you've had a little break and relaxed, try finding the bug again. You'll approach the problem with a refreshed vision that's often quite illuminating. Incubation works because it breaks you out of a (dare I say it?) dysfunctional mind set. If you follow a wrong path for too long, you sometimes get stuck with no room in which to turn around. The best thing to do when this happens is find a way to start down a new path. I know it's touchy-feely, but it works. Really!

10. And only if all this doesn't work... Ask your "begeleider" for help. Sometimes you wear such a rut in your problem with repetitious thought patterns, only someone else can see the hole in your "logic".

11. The absolute best way to eradicate bugs... Create bug-free code from the get-go. Win before you fight!