How To: Debug a Program -- Top 10 Debugging Tips

  1. Take the time to plan your program before you start coding. It will actually be quicker to write your program than if you don’t do this!
  2. Create an algorithm (like as if you had to explain what needed to be done to a child who has never done this before) for how someone would do what the program is going to do.
  3. Check for syntax errors (violating the rules of the programming language). For instance, missing a semi-colon.
  4. Check for run time errors (asking the computer to do something it cannot do). For instance, dividing by zero, or accessing a part of undefined or inaccessible part of memory.
  5. Check for logic errors (your planned algorithm does not produce the results you expected). For instance, your algorithm to calculate the average height of everyone in the room based on how you would do it manually, doesn’t come up with the same answer as you did counting and adding and dividing the numbers yourself.
  6. Play computer and execute your program instruction by instruction by keeping track of every variable or data structure in memory and output on a piece of paper. Compare to what your program executed. The computer does what your program told it to do.
  7. Put temporary output statements to see what instructions and sub programs are being executed and what the value of variables and data structures are at given points in the program execution.
  8. Break the programming problem or objective down into steps and parts, and first make small experimental programs to do each part or step and get that to work, before putting together the entire program.
  9. Test every feature of your program at least once. Do not make invalid assumptions about input data. Make user input to any program simple and easy!
  10. The first listed compiler error is always a true error; however, later errors may not be true errors. A compiler error may be caused by any source code line above the line referred to by the compiler; however, it can not be caused by a line below. Interpreters on the on the other hand, are reading instructions in advance, especially if they are pipelining the machine cycle (1. fetch instruction; 2. decode instruction; 3. execute instruction; 4. store results) so listed errors might not be the line in which the error occurred.