(( I write some code and then immediately step through it line by line with the debugger to make sure that it's working as I expected. Occasionally, I find errors or mistakes I wasn't expecting.

I'm pretty good with the debugger, but not good enough to read x86 assembly. Here are some tips for you:
-Keep your code clean, simple and readable. Whitespace is good for preventing eye strain and information overload.

-Every time you use a 'new' keyword to allocate memory, automatically create a 'delete' keyword to deallocate it and make sure that the delete is reached.

-Be consistent with your naming conventions.

-Comment your code. It's for you. When your eyes are bleary, your brain is mush, or six months from now when you have to relearn your code, you'll be happier to read comments than code to figure out what you were thinking.

-floating point precision errors are a bitch to find and debug. If you're comparing floats for equivalence without a tolerance threshold, you're doing it wrong.

-If you're creating a mathematically oriented function and you know the range of valid inputs, throw it into a for loop and iterate through each valid value. Did you get divide by zero errors? did you handle negative values properly? if you're using floats, was your step size small enough to test for floating point precision errors?

-Sometimes it helps to create classes in a seperate project so that you can test and develop them in isolation. Once you know that your class and its member functions are rock solid, you can copy them into your main project and have a higher degree of confidence that they'll work without problems. This also helps to keep your classes loosely coupled.

-Aside from the debugger, my second most useful tool for debugging is pen and paper. Draw out the conceptual idea you're trying to implement and then synchronize the steps with the debugger (example: inserting nodes into a linked list at the front, tail and middle).

-The best bugs are the ones you don't have. A little bit of planning before code writing will go a LONG ways. There are three types of errors: Syntax errors, program errors, and design errors. Syntax errors prevent you from compiling. Program errors are stuff like referencing a null pointer or dividing by zero. Design errors are when you code a program with a broken design and you don't realize it until hours/days/weeks/months later. Planning and diagraming helps avoid them and helps keep your code organized.

-Lastly, stay disciplined. It's easy to get lazy and code something up really quick, but I've found that taking a little bit of extra effort to do things right the first time saves more time and effort since I don't have to refactor what I did out of laziness.

Good luck!

This thread is really becoming a very valuable reference for me (and hopefully others too!)

I completely wasn't aware garbage collection was *not* automatic in C++.

But wait, if I do use:


int b = 0;


and then use b all I want. Do I have to worry about garbage collecting such variables? Or do those get garbage collected automatically?

You only have to worry about memory in C++ when it is allocated via new (or malloc, if you're working with C). If you don't create the variable with new, you don't have to delete it. So yes, you can use b all you want and not worry about cleaning up. However, if you did the following, you would have to worry about cleaning up:


int* b = new int;
// Use b all you want, but be sure to delete it when you're done, or else memory will get leaked!
delete b;


You may find my articles of use.
Memory Management and general safety procedures.
Organizational guidelines including file naming etc.

You can ignore the naming conventions section in the second link if that is not your bag. Everyone has his or her own style.
The part following that (Structure) is generally more widely accepted as good practice, and I made an effort to explain why each guideline exists rather than just to spew them out.


L. Spiro