Scor­pio News

One of the more grisly aspects of computing is to read some of the glossy magazines sold for the profit of the publishers and the edification(!) of the users of plastic box computers. Apart from the ads., the program listings are often so dreadfully or densely printed in minuscule type that it is a major business trying either to read them or (worse) type them in. Multi-statement lines up to 250 or so characters in length do little for one’s understanding of program logic!

Quite a number of commercially published programs appear to have been written in such a way that only the most dedicated ‘hacker’ will try to disentangle the program logic – the reason being to discourage the phantom fiddler; such techniques are to be deplored as ave programs which are inadequately documented or commented.

There are four basic properties that any computer program should have, regardless of whether it is to be offered for sale, placed in the public domain or used by the originator for his own purposes.

1. It should be logically constructed and portable (i.e. able to run without a great deal of modification on many machines).
2. It should be easy to follow and well documented.
3. It should work properly, giving correct answers or behaving in the manner indicated by the author.
4. It should run without excessive demands upon memory or CPU time.

A good program should be constructed so that it is user friendly at all stages; regrettably, few are. Brown and Sampson (1973) compare a good program with an amiable, large dog – not easily ruffled, slow to take offense and difficult to divert from its chosen course (they don’t mention the large appetite of large dogs – excessive processing time or memory usage, perhaps?) A little unfairly, they go on to liken most peoples’ efforts at programming to poodles (very finnicky about their food, demanding only the very best and tastiest titbits, very quick-tempered, easily upset and generally more trouble than they are worth). All this is possibly unfair to poodles but does apply to most software that I have seen (and to a lot I have written). The worst offenders seem to be authors of programs in BASIC, closely followed by FOR­TRAN and PASCAL practitioners

Good Design

Many of us, when faced with a problem which needs the attention of a computer, tend to jump in feet first with a rash of statements in whatever language we think we are most proficient at using. This isn’t the best way except for the most trivial applications.

Define the problem – what it is and the best way to go about it.

Is a good program already available which will do what you want (or which can be easily amended for this purpose)? Do you know what you want to do, and how the computer can help you do it – there is no point in trying to write a database program if you don’t know what a database is. Do you really need to use a computer or would a few minutes with a calculator serve just as well? If you can use another’s program, would your data be in an appropriate form or does it need prior processing?

Having defined the problem, one should then outline the program, specifying its purpose, the types of data input and output, the variables to be included and the mathematics which may be needed, At this stage, it should also be possibly