FORTRAN Statements

This section covers standard applying to specific statements.

• Statement format RULE: Must not contain the TAB character and continuation should be limited to 19 lines maximum. Source must not continue beyond column 72 and it is recommended that comments should not exceed column 80.

• Statement ordering RULE: Must adhere strictly to the FORTRAN 77 standard. For example DATA statements must appear after specification statements. If in doubt, consult any standard reference language manual or see figure 7 on page 95 of Mike Metcalfe's book.

• Default initial values RULE: Never assume that the compiler will assign a default initial value to a variable i.e. always assign a value at compile time (DATA statement) or execution time (assignment statement) before using the value.

• ASSIGN GOTO RULE:Is banned.

• Comments In-line comments preceeded by a ! are allowed although not standard.

• DATA RULE: Don't use in conjunction with SAVE if ZTELL could be called, directly or indirectly from the routine. See section 11. Use PARAMETER instead, if the value never changes during execution, to avoid all these difficulties. Also don't define general physical or mathematical constants such as the velocity of light or $\pi$ in individual routines, these should be added to contants.inc.

• DO ...ENDDO and DO WHILE ...ENDDO. Allowed although not standard.

• IMPLICIT NONE RULE: use even though not standard. Using constructions like:-

  IMPLICIT REAL (A-H, O-Z)

  are not permitted except when adding external source with minimal modifications.

• INCLUDE RULE: Use even though not standard. All file names specified in INCLUDE statements must be lower case.

• I/O Statements RULE: Must use standard unit numbers defined in the include files qunit.inc or io.inc. Units 90..99 are reserved for user code.

• RETURN RULE: The use of the alternate returns, e.g. RETURN 1, is banned.

• SAVE RULE: Don't use in conjunction with DATA if ZTELL could be called, directly or indirectly from the routine. See section 11. It is strongly recommended that, if a routine requires to save the value of any of its local variables, a blanket SAVE (i.e. one without any variables specified) be used rather than identifying the individual variables. This may waste a little more memory but avoids the risk of forgetting to update the SAVE statement if making changes to the routine at a future time.

• STOP RULE: is banned (except at the end of the program!). Use ZTELL instead, see section 10.

• SUBROUTINE. Where a subroutine returns an error flag, it is recommended that it be the last parameter, with a name such as IRETC (RETurn Code), and follows the convention:-

  $>$ 0 failure of some kind

  $\leq$ 0 success of some kind

  Also the asterisk argument, used to specify alternative returns, is banned.

• ENTRY. Avoid using this statement if at all possible as it makes code management more difficult (cannot determine source file from name) and can lead to poor structure (by coupling loosely related code together). If necessary and the routine requires that local variable values are retained between calls then the SAVE statement must be used, with all the warnings that this implies. See section 11.