NOT! the Starlink Programming Standards
This survival guide appeared in 1988, when
compilers were noticeably worse than they are nowadays and the computer
science graduates were noticeably more dogmatic.
Prologue
It is time that those who have enjoyed the
growth of FORTRAN from a crude, unreliable staccato of limited scope and
bedevilled with having to add up character field widths and putting up
with SAYING EVERYTHING IN CAPITALS into the flexible, suave and debonair
Proper Meta-Language of today, capable of clear linguistic communication
and fast, precise, wide-ranging logic and used the world over by the world's
brainiest boffins (constricted now only by the quaint 72-column field width)
arose to combat the creeping menace of the Sensible Computer Language Ergonomist,
often in a boring anorak or a depressing suit, who would have a mish-mash
of ALGOL- and UNIX-like disadvantages boring into its heart like a Shakespearean
canker until the whole thing became yet another verbose and embarrassing
white elephant...
General
The consequences of any error should be graceful.
Code should be as condensed as possible. All FORTRAN should be written
in upper-case except for the contents of strings. Comments and blank likes
are tiresome and not recommended, except possibly at the beginning of a
segment or in test code, when they should just be prefixed C(space). Superfluous
spaces should be avoided except surrounding IF (), GOTO, DO, ASSIGN etc.
Long lines of code should use the full 72-column width and continue with
a sequence of continuation symbols (hopefully, the 72-column restriction
will disappear soon). Code terminated at a space owing to continuation
onto the next line should not rely on that space being seen at the end
of the preceding line. Inaccessible code is obviously the result of an
embarrassing mistake which must be rectified immediately. Bad code is written
by somebody else.
Names
All integer and logical variable, array and
function names (and no other types) should begin with I, J, K, L, M or
N. Double-precision function names should preferably be prefixed with D.
Character variable and array names should preferably begin with C (watch
out! they are only available from some manufacturers).
Operations
Thoughtless truncations and mixed-mode arithmetic
are forbidden as hallmarks of an amateur thinker! Optimisation should be
done insofar as possible, especially the avoidance of repeated evaluations
of the same expression. All variables must be set before being read. Variables
should not be set if they will not be used before exit. It is wasteful
to set a variable if its value is definitely to be used only once. No local
variable can be assumed to remain unchanged after exit from its segment,
and will need to be re-set before being re-read. Local variables should
be re-used wherever possible. There is no point in testing for equalities
between real variables. COMMON blocks should normally match, even if only
partly used in a segment. Dummy array dimensions should not merely be called
(1) in the anticipation that a longer one will actually materialise. EQUIVALENCE
of identical entities should be avoided in favour of uniform naming. CONTINUE
should be used only when a skip is required to the end of a DO loop. A
DO loop which would be executed 'zero' times should be skipped around.
The three-branched IF must have three different destination labels.
The IF ... THEN ... (ELSE) ... ENDIF and DO (WHILE) ... ENDDO constructs,
requiring as they do great voids of blank space in order to make sense,
are very tiresome and should be avoided. There is nothing whatsoever wrong
with GOTO: it is brief and completely explicit.
Pathways and I/O
All files should be opened by user-library
routines. Program execution should be stopped by a user-library routine.
All segments except the master should contain one RETURN, although emergency
stopping calls are permissible (with explanation). Interactive input should
usually be minimised to avoid tyranny. Jobspace variables etc etc
can be sent in from elsewhere with a user-library routine. Input should
be flexible, free-format wherever possible, and tolerant of minor errors
at least. It should be checked for validity. Character instructions should
not normally be case-sensitive. Output should be minimal, precise, well-formatted
and grammatical. Kindergarten capitals, superfluous spaces, nonsignificant
digits, numbers imperfectly registered within text and multiple rows of
asterisks, blank lines etc are particularly naff. Page throws should
normally be avoided. Output tables should have column headings and a blank
line after every five printed. A brief confirmation of 'Completed' or 'Abandoned'
should appear at the end of output. Remember what is happening to the world's
rain forests. Finally - it is unacceptable to discuss programming in the
presence of lay persons in case their suspicions are confirmed.
Epilogue
Naturally one or two minor difficulties might
arise over support for the program; but a policy of keeping the author
on a permanent retainer whilst the program was still needed, and insuring
her/his life for enough to pay for a complete replacement if the Reaper
came, would ensure that (provided the individual was of sound mind and
the task to be solved was actually possible) an agreeable balance could,
on average, be struck between development, indestructibility and renewal.
It is fortunate that this is not addressed to the hard-headed types who
practise COBOL.
Jon Godwin, Oxford University
(Starlink Bulletin 1988;
1: 11).
[End of document, updated to 26 March 1997]