15. Making your programs work

There is more to the art of programming computers than just knowing which statement does what. You will probably already have found that most of your programs have what are technically known as bugs when you first type them in: maybe just typing errors, or maybe mistakes in your own ideas of what the program should do. You might put this down to inexperience, but you would be deluding yourself.

EVERY PROGRAM STARTS OFF WITH BUGS.

Many programs finish up with bugs as well. There are two corollaries to this; first, you must test all your programs straight away; and second, there's no point in losing your temper every time they don't work. The general plan can be illustrated with a flowchart:

The idea is that you follow the arrows from box to box, doing what it says at each one. We have used different sorts of boxes for different sorts of instructions: 

A rounded box		is start or finish.
A rectangular box		is a straightforward instruction.
A diamond		asks you to make some kind of decision before carrying on.

(These shapes are fairly widely used, but nothing earth-shattering depends on them.)

Of course, these flowcharts are ill-adapted for describing human activities; thinking along fixed straight lines like this is not good for creativeness or flexibility. For computers, however, they are just the job. They are best at describing the large-scale structure of programs, with a subordinate in almost every box, so a flowchart for our sterling example in the last chapter might be.

Conceptually, then, rectangular boxes correspond to GOSUBs; 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; and 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

1. Check that there are no typing errors. Always do this.
2. 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.
3. 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.
4. You might be able to step through a program line by line by typing in its lines as commands.
5. 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 original 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.