Contents

"As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs." — Maurice Wilkes discovers debugging, 1949

By now if you have been messing around with the programs you have probably found that sometimes the program does something you didn't want it to do. This is fairly common. Debugging is the process of figuring out what the computer is doing and then getting it to do what you want it to do. This can be tricky. I once spent nearly a week tracking down and fixing a bug that was caused by someone putting an x where a y should have been.

The first thing to do (this sounds obvious) is to figure out what the
program should be doing if it is running correctly. Come up with some
test cases and see what happens. For example, let's say I have a
program to compute the perimeter of a rectangle (the sum of the length
of all the edges). I have the following test cases:

height

width

perimeter

3

4

14

2

3

10

4

4

16

2

2

8

5

1

12

I now run my program on all of the test cases and see if the program does what
I expect it to do. If it doesn't then I need to find out what the computer is
doing.

More commonly some of the test cases will work and some will not. If that is the case you should try and figure out what the working ones have in common.
For example here is the output for a perimeter program (you get to see the code in a minute):

Height: 3
Width: 4
perimeter = 15

Height: 2
Width: 3
perimeter = 11

Height: 4
Width: 4
perimeter = 16

Height: 2
Width: 2
perimeter = 8

Height: 5
Width: 1
perimeter = 8

Notice that it didn't work for the first two inputs, it worked for the next
two and it didn't work on the last one. Try and figure out what is in common
with the working ones. Once you have some idea what the problem is finding the
cause is easier. With your own programs you should try more test cases if you need them.

The next thing to do is to look at the source code. One of the most important things to do while programming is reading source code. The primary way to do this is code walkthroughs.

A code walkthrough starts at the first line, and works its way down until the program is done. While loops and if statements mean that some lines may never be run and some lines are run many times. At each line you figure out what Python has done.

Lets start with the simple perimeter program. Don't type it in, you are going to read it, not run it. The source code is:

Answer: The first line is always run first. In this case it is: height = input("Height: ")

What does that line do?

Prints Height: , waits for the user to type a number in, and puts that in the variable height.

What is the next line that runs?

In general, it is the next line down which is: width = input("Width: ")

What does that line do?

Prints Width: , waits for the user to type a number in, and puts what the user types in the variable width.

What is the next line that runs?

When the next line is not indented more or less than the current line, it is the line right afterwards, so it is: print "perimeter = ", width + height + width + width (It may also run a function in the current line, but that's a future chapter.) What does that line do?

You need to figure out what the program is doing. You need to figure out what the program should do. Figure out what the difference between the two is. Debugging is a skill that has to be practiced to be learned. If you can't figure it out after an hour, take a break, talk to someone about the problem or contemplate the lint in your navel. Come back in a while and you will probably have new ideas about the problem. Good luck.