rules for tracking down the cause of a problem

From: Progmatic shelf-practical programming an introduction to computer sicence in python,  12.4 Debugging

Here are some rules for tracking down the cause of a problem:

 

1. Make sure you knowwhat the program is supposed to do.Sometimes

this means doing the calculation by hand to see what the

correct answer is. Other times, it means reading thedocumentation

(or the assignment) carefully or writing a test.

 

2. Repeat the failure. You can debugthings only when they go wrong,

so find a test case that makes the program fail reliably.Once

you have one, try to find a simpler one; doing this oftenprovides

enough clues to allow you to fix the underlying problem.

 

3. Divide and conquer. Once you havea test that makes the program

fail, try to find the first moment where something goeswrong.

Examine the inputs to the function or block of code where the

problem first becomes visible. If they are wrong, look at howthey

were created, and so on.

 

4. Change one thingat a time, for a reason. Replacing random bits of

code on the off-chance they might be responsible for yourproblem

is unlikely to do much good. (After all, you got it wrong the

first time....) Each time you make a change, rerun your testcases

immediately.

 

5. Keep records. After workingon a problem for an hour, you won’t

be able to remember the results of the tests you’ve run. Likeany

other scientist, you should keep records. Some programmersuse a

lab notebook; others keep a file open in an editor. Whateverworks

for you, make sure that when the time comes to seek help, you

can tell your colleagues exactly whatyou’ve learned.