THE BEGINNER'S PAGE
Richard Mansfield, Senior Editor
Trapping Bugs
It was a moth, according to legend, that caused a program to crash in the early days when computers were built of vacuum tubes and tons of copper wire. The critter had flown into the machine. From this we get the term bug, meaning that there is an error, a problem in a computer program. And tracking down bugs is called debugging.
As all programmers soon learn, there is no permanent cure for bugs—they are always hiding inside a freshly written program of any complexity. Some bugs are obvious and will show up the first time a program is tried out. Some are hidden away and permit most of the program to run without error. A complex program might run well for weeks or months and then a particular sequence of events will trigger a well-hidden bug.
Program Sketches
For many, programming is similar to painting or sculpting. First you jump in and roughly create the outlines, the main ideas. At this point you've essentially made a sketch of the final program. Then you start testing the program by RUNning it, refining it until it performs as it should.
What are the best ways to look for bugs? Luckily, the most common bugs, typos, are reported to you by BASIC itself. On the Atari, if you try to enter a line like this: PRINF X, you will get an immediate SYNTAX ERROR report. Other versions of BASIC wait to report typos until after you RUN the program, but the effect is the same. Your computer tells you what's wrong and which line to fix.
Many other bugs show up quickly when you first try out the program: Nothing appears onscreen; things appear, but in the wrong places; or the numbers are all wrong. In other words, the program isn't even coming close to your expectations. These are often easy bugs to work with because they aren't usually caused by the interaction of two parts of your program. There's some gross failure somewhere. You've simply got to look at your formatting routine or your mathematical definitions to see where the problem is.
Between The Cracks
Some of the hardest bugs to find are hidden in the cracks. They are usually the result of a clash between two otherwise perfectly functional subroutines. For example, if your program uses the variable T to stand for the total of an addition problem and then you use a subroutine with a loop that also uses T:
10 T = BOLTS + WASHERS . . . 800 FOR T = 1 To 500
As you can see, no matter what your total of bolts and washers is, it will be left at 500 anytime you use the subroutine at line 800.
A similar interaction between variables can be even more subtle. In many versions of BASIC, only the first two letters of a variable name have any significance. So, if you name one thing BOLTS and another thing BOWLING, these two things will appear to the computer as a single variable called BO. And, as in the example above, the most recent number assigned to BO will be the only value that variable can have.
The Worst Bugs
But the worst bugs are not in the computer at all. They're in the programmer's mind. And since you must use your brain to ferret out the errors caused by that brain—you can see the paradox. These errors tend to be of two types: incorrect setups and bad logic.
An example of an incorrect setup would be thinking you've defined a variable when, in fact, you haven't, or using > when you mean <. The variations on this theme are endless and you can look at > dozens of times and not even stop to think about it as a possible source of error.
Bad logic would include such things as subroutines which exit via GOTO instead of RETURN; INPUT at the wrong time; or forgetting about the first or last item in a sequence like a DATA list.
Sometimes there's only one way to find a deeply hidden bug: stepping through the program. There are two levels of step testing. You can insert STOP in various places, then check to see that the variables are what they should be at these stopping points. Then CONT to the next STOP and ask to have the variables printed again (type: ? X,Y,Z$). This rough test is often enough to pinpoint the place where the program has gone wrong.
Alternatively, you can use the single-stepping TRACE function found in many programmer's aid programs. These aids add commands to BASIC like RENUMBER, DELETE, and usually have a single-stepping function as well.
When you activate a TRACE command, your program executes step by step, one command at a time. After each command, the status of all active variables is displayed on screen along with the program line so you can locate where things begin to come unglued. Often, a TRACE function permits you to define how fast it will execute and even allows you to turn it on or off from within the program. TRACEing is a slow, but nearly always successful way to trap the most devious bugs.
If all else fails, it's sometimes advisable to ask for help from a friend. His brain won't have been implicated in the original error, and he can therefore often spot the > you keep ignoring.