Sign in to follow this  
Ainokea

Tips for debugging your programs?

Recommended Posts

When you have that awful runtime bug in your program where something isnt rendering right or your movement is messed up how do you go about fixing it? Is their some sort of debugger that can help you? Or is the only way to carfully check your code line by line?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this