Scor­pio News

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.

Presentation

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.

Documentation

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!

Integrity

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 message.