Ideally, you should test each routine with every combination of variables possible, this is especially true when you are asking users to enter information. It's little use turning to the person that just crashed your beloved masterpiece to frustratedly exclaim, "Well, what did you press that key for anyway?". Your program should handle both invalid and valid inputs.
One of the things that separates good programmers from indifferent ones is the ability to seek and destroy bugs in code. (An ability to admit that you're wrong sometimes doesn't go amiss either!) Largely this skill is won through experience and downright pig-headedness: it's only a machine, I won't let it beat me. There are several techniques that can help here. In this section, we'll cover some. Please keep in mind that the list is not exhaustive. Every bug will have a slightly different solution and sometimes you just have to invent your own methods.
This discussion will completely ignore the syntax errors that occur when you misspell a variable name or keyword and BASIC squeals 'Mistake at line 1230'. What we're concentrating on is when the program runs smoothly enough, but just won't behave quite as expected.
The first tool in our armoury is our old friend PRINT. Not sure why your WHILE loop never exits? Put a PRINT in the loop with the variables that dictate the exit condition and watch the results scroll up the screen. There are times when too many PRINTs can spoil the display that should be on the screen, or the data changes too fast to see. In either of these cases you can use PRINT TAB to put the results somewhere out of the way and then have a dummy input line which stalls the program giving you control of when the data changes.
Line 5 just waits for any keypress and throws it away, thus stalling the loop. You can make this conditional in order to save key presses and time.
REM Pausing a loop FOR I%=1 TO 10 REM spaces at end overwrite previous data PRINT TAB(0,24);I%;" " Dummy$=GET$ NEXT I% END
The other command that can be embedded in our code is TRACE. TRACE is used with ON and OFF. When BASIC comes across TRACE ON, it will print every line number in square brackets until it encounters TRACE OFF or the program ends. Obviously, you need a program with line numbers to use this. Don't depend on seeing anything that the program is supposed to print out here because it'll zip past in a blur of line numbers. This command is more useful when you want to trace the path that the program takes for a given set of variables.
REM Pausing a loop FOR I%=1 TO 10 IF I%>5 AND I%<8 THEN PRINT TAB(0,24);I%;" " Dummy$=GET$ ENDIF NEXT I% END
TRACE will only display the line number when the line is first executed. If you have a loop in a line like this:
10 REM TRACING a program 20 TRACE ON 30 FOR I%=1 TO 10 40 PRINT TAB(0,24);I%;" " 50 NEXT I% 60 TRACE OFF 70 END
The line will only show once in the trace despite the fact that BASIC is pounding round the loop looking for a keypress.
120 REPEAT : UNTIL INKEY$(0)
TRACE will also accept a line number as a parameter. The idea being that it will only print line numbers less than the one specified. If you write programs as is described in the final section of this tutor, all the PROCs and FNs come after the END, so by using the line number of the END instruction, you will get a view of the overall structure of the program.
I'm not giving too many examples here as the BBC BASIC editor has an excellent debugging tool that eclipses the above methods. Sometimes, even if it's just for inspiration, it's useful to have some other tricks up your sleeve and the above two have been around since BBC BASIC was first written.
There are several buttons in the same block as the immediate button. You have probably used the run button (large black arrow) and possibly the stop (black square). We'll now cover the other two, but first shall we have a program to test with?
Here is a trivial bug. When PROC_Oops runs, it declares a local I, but sets the global I% to 10, hence the loop ends after just one iteration. We will now use the debugger to track this fault.
REM Debug demo FOR I%=1 TO 10 PRINT I% PROC_Oops NEXT I% END DEF PROC_Oops LOCAL I I%=10 ENDPROC
There is an option that allows us to go through the program one line at a time. To demonstrate this, put the editor's cursor on line 3, with the PRINT statement; it doesn't matter where. This time, instead of pressing Run, select the Run menu and click 'Run to cursor'. The Pause button on the toolbar is shown pressed and the Step button comes to life. Every time we press the Step button the program advances to the next line and waits. By stepping through, we can verify that the loop is executed just once. Do this and notice that we lose the Pause when the program ends.
Put the cursor back on line 3. Select 'Run to cursor' and when the pause becomes active, open the variable list. Step through again. When the program gets to PROC_Oops it creates a local called I, you can see it appear in the list. Stepping through into PROC_Oops, we see I% change value, not I as was expected. Round about now the cause of the bug hits us so we don't need to single step anymore. By clicking Pause, step is released allowing the program to end at normal speed. We can now correct our little bug, feel really pleased with ourselves and then mentally chastise ourselves for putting it there in the first place.
|
APPENDIX E
|
