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.


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


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.


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


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.


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]