Debugging. Your program is supposed to do something, but does something else.

A breakpoint is a place where you tell your program to pause:

When the program pauses, you can look at the values of variables. Put the mouse cursor on a variable in the code. Does it have the value you expect? For example, if you expect the value to be 20, but it's 13, then you know there's a bug somewhere above the line with the breakpoint.

Where to put breakpoints?

Say you have a program that does some output on line 68, say putting a value in cell (2, 3). The output is wrong; it should be 50, but it's 30. You know the problem is somewhere above line 68, but where? You can add breakpoints, and compare variables' values. But where do you put your first breakpoint?

From the top

One strategy is to put a breakpoint on the first executable line of your program. Step through one line at a time. Look at the value of each variable as it is computed. That's OK for small programs, maybe up to 10 lines. But for longer programs, it might take too long. If the program is 68 lines long, and the bug is on line 55, you'll have to step through most of the program until you find the line with the bug.

You want to find the bug more quickly. Let's figure out how.

Guessing numbers

Here's a simple game. Figure out the computer's number in as few guesses as you can. Try it a few times. Work out a strategy.

This strategy is called the half split. You can use it to find bugs, as well. In the number game, you choose the number halfway between the low and high point. So if you know that the number is between 1 and 50, choose 25. In debugging, put the breakpoint on the line of code that is halfway. So if you know the bug is somewhere between line 1 and 68, put a breakpoint on line 34. That's halfway between. Then look at the values of variables. If they aren't what you expect, then you know the bug is between lines 1 and 34. If the values are what you expect, the bug is somewhere between lines 35 and 68.

The second game

Like the number guessing game, but with lines of code.

Find the bug.

The third game

It's about the variables. If a variable has the value you expect, no problem. Suppose you're looking at line 18 of the code. You expect the variable cost to have the value 35. Using the debugger, you see that the value is 35. Yay! No problem, up to that point.

Then you look at line 54. You expect the variable cost to have the value 72. Using the debugger, you see that the value is 86. Ack! Not the same. The problem is somewhere between lines 18 and 54.

Try this game. Find the bug with as few guesses as you can.

The fourth game

One more game. No color coding this time. The method's the same, though. Do the half split, comparing the actual and expected variable values to decide whether the bug is above or below a line you're selected.

h1. The debugger

Here's the screenshot that was at the top of the page:

See how it's like the last game? You put a breakpoint on a line. Then you compare the values of variables on that line, with what you think they should be. If they're different, there's a bug somewhere above the line.

How do you decide where to put the breakpoint? The half split pattern.

Summary

Debugging. Your program is supposed to do something, but does something else. A breakpoint is a place where your program pauses. Sometimes the nature of the bug gives you hints as to where you should put breakpoints. Sometimes you have no idea where the problem could be. Use the half split.