A useful list of basic BASIC statements and commands is given in Monro (1978).
I don’t think that either of the usual PASCALs (Hi-Soft and COMPAS) give any
indication of which of their statements and commands are non-standard as far as
the ISO definition is concerned, but Prospero’s Pro-Pascal and ProFortran do.
Is is always a good idea to include in a REM or COMMENT statement, the version
of the language which you have used if it is not the ‘portable’ type.
This is one bit of program development which is so often skimped. A fabulous
program which has all the bells and whistles one could ever imagine and which
everyone will want to use isn’t going to inspire much confidence if the listing
is untidy, disorganized or poorly commented. An incompletely commented program
might be all right if it works all the time but what happens if you want to
modify it later and you’ve forgotten why you put in particular bit of code.
Are your variable names sensible – it is helpful to use T for the sum of a
series of numbers and N for the total umber of observations – rather than Q or
Z for example? Screen or printer output should be helpful – if you want a
response to a prompt on the screen, put in a few words to request the input –
such as ‘Number of observations’. Similarly, results, whether on the screen or
printer should have some explanation – auch as headings for columns.
‘Prettyprinting’ is a rather ‘twee’ way of expressing the advantage of (for
example} indenting parts of a program listing – it was first used by Nagin and
Ledgard in 1978 as a means of pointing out the advantages (for following program
logic) of various levels of indentation caused by typing spaces before the
statements – thus nested FOR...NEXT loops could be traced very easily if the
second and subsequent loops were indented by 2 of 3 spaces. COMAL does this
automatically. A tidy screen or printer display of results is more easily
understood and some ‘prettyprinting’ here is achieved by spaces or the use of
tabs or particular print field descriptors The readability of a listing is
improved by blank comment lines in appropriate places.
For many people, particularly those not familiar with a program, adequate
documentation is essential, so its provision is a major and often disliked part
of program development. If a program is for your own use, why bother? The
trouble is that one’s memory is not faultless and a lot of time and temper can
be wasted, A good example of documentation is that provided with the various
PEN programs – well set out and comprehensible to the average dodo. We all know
of bad examples!
In an ideal world, our carefully written, well-documented program would produce
the right results from whatever data we stuffed into it – or it would do in
other ways, what it was designed for. Unfortunately, this is rarely the case
and even after extensive debugging, it may still refuse to function properly. A
program should, once it has been found to be error-free, both in terams of syntax
(confusion of 1 and I, 2 and Z or 0 and O, for example or the wrong number of
brackets) and the results obtained, be ‘error-trapped’ so that an incorrect or
out-of-range input does not throw it into a state of utter confusion so that the
machine crashes or an incorrect result is output. This takes a litte time to
organise but is well worthwhile. Test data may work perfectly but real data may
produce odd results so one’s test data should, where possible, include values
lying at the extremes which are likely to be encountered. Commercial packages
are variable in this respect – some ‘throw a wobbly’ if bad data are encountered
but the majority are designed to cope with this eventuality and allow some user-intervention
to correct the situation after the package bas produced an error