Tips for debugging your programs?

Display important variables.

Set lots of breakpoints. Even if you don't think there's a problem.

Ooh, commercial for the Animatrix...wish I'd seen it before I bought it, though.

KID'S STORY R0X.

use asserts everywhere.

Make a logging class/library rutine you can use in all your programs... Log Everything

Where do I begin?

* Create and test objects in their own project if possible
* Make sure your classes do one thing only, and do it well
* Make sure your functions do one thing only, and do it well
* Assert like mad -- they are free
* If the current section of code feels like it is out of control, it probably is
* If the current section of code smells, it probably stinks
* Make sure you're at the proper level of abstraction. Don't be afraid to add additional layers if it helps you express the solution more clearly
* Don't write a bunch of code without testing it
* Conversely, eyeball your code and look for boundary conditions
* Learn to match up an address in your executable image up with a line of code so you can pinpoint the location of a crash
* Be patient, and calm
* Explain the problem to someone, you may already know the solution but have trouble putting it into code
* Don't stress yourself

This is a very good book if you're using Visual Studio.

If the program is running fine, but doing the wrong thing, then adding additional, secondary visualization might help. For example, if objects seem to spin around un-known points, you might have a bug in your matrix library, or a bug in how you use it, or a bug in how you think about it. Try putting the modelview matrix to camera-only (or, in D3D, VIEW to identity), and get the orientation of your objects; then manually plot lines from the center of the object out through the X, Y and Z basis vectors of that orientation.

If your physics is out of control, draw some simple statistics to screen (or file): number of contacts generated per frame; which objects contacts are generated between; amount of force and torque accumulated per frame (and from where!); what the actual inputs used are; etc.

Always try to reduce the problem to the smallest possible. If you have a level with 100 items in it, does the problem still happen when you have 3? If not, why would more items cause it to fail? If it does, well, you have an easier time looking at all the data in the level!

Unit testing. You'll find you won't have to use the debugger so much.

assert invariants.

use standard libraries.

Quote:

Original post by Arild Fines This is a very good book if you're using Visual Studio.

Be sure to buy it used - it is going for only $4.94! Skeptical, I ordered a "like-new" edition and can easily say its the best $6.18 I ever spent.

I do not agree with Robbins on every point, but he is quite intelligent and well-spoken.