Conceptually, then, rectangular boxes correspond to
GOSUB
s; although in practice some boxes - like
the one above that inputs L, S & D - are translated directly into BASIC statements, without a subroutine.
Anything - like flowcharts, subroutines, & also
REM
statements - that makes the program clearer gives
you a better understanding of it; & then you are bound to write fewer bugs. But subroutines also help you
get out the bugs you've written anyway, by making the program easier to test. You will find it much easier
to test the subroutines individually & make sure that they fit together properly, than to test a whole
unstructured program.
Subroutines, then, help with the box 'find the bugs' & this is the box where you need all the help you can
get, for it is often the most exasperating. Other hints for finding bugs are
(i) Check that there are no typing errors. Always do this.
(ii) Try to work out what all the variables should be at each stage - & if possible explain this in
REM
statements. You can check the variables at a given point in the program by inserting a
PRINT
statement
there.
(iii) If the effect of the program is to make the program stop with an error report, then use this information
as thoroughly as you can. Look up the report code, & work out why it stopped on the line where it did. Print
out the values of the variables, if necessary.
(iv) You might be able to step through a program line by line by typing in its lines as commands.
(v) Pretend to be the computer: run the program on yourself using pencil & paper to note down the
values of the variables.
Once you've found the bugs, fixing them is much like writing the origional program, but you must test the
program again. It is surprisingly easy to fix one bug, only to introduce another.
Exercises
1. The flowchart for the LSD calculator has no 'finish' box. Does this matter? Where would you put one if
you wanted to?
2. Write flowcharts for the looping programs in chapter 12.
To Next Page
Loading...
Need help?
General
