The purpose of a FORTRAN standard is to ensure that the FORTRAN code will be as portable as possible as well as be consistent throughout the system. This standard covers information on how to write code.
The following material is based substantially on a summary by the author of Chapters 8 and 9 of the book Effective FORTRAN 77, Michael Metcalf, Oxford University Press, 1985, ISBN 0198537093.
This section follows the scheme of classifying each point according to its position in the language and its relevance, either to portability or to programming style. Points marked with two asterisks should be regarded as mandatory for readable, portable code; one asterisk indicates that the point is important; unmarked points are to be considered only as desirable. In general, exceptions are allowable where either an external convention, such as a mathematical notation, is regarded as more relevant or where automatic tools are available to transform nonstandard code into standard form.
** (a) Use standard FORTRAN-77. Avoid compiler dependent features. * (b) Use only the standard character set, avoiding lower case characters except in comment lines. The only permitted special characters are: blank , . ' : = + * / ( ) $ * (c) Do not use any nonblank characters in columns 1 through 5 of a continuation line. ** (d) Do not use any other source format than the standard one (1 through 5: label, 6: continuation, 7 through 72; statement). * (e) Do not write more than one statement per line. * (f) Do not use blank lines. * (g) Leave column 2 of comment lines blank to avoid problems with some source code management systems. ** (h) Do not use inline comments following an exclamation mark (!). ** (i) Do not use more than six characters in a name. Always use a letter as the first character and only letters or numerals for the remaining five possible characters. ** (j) Do not use the currency symbol ($) in a name. ** (k) Do not use more than 19 continuations for any one line of code.
(a) Do not insert comment lines between continuation lines or between program units. * (b) Do not split a name between two lines. (c) Use an asterisk (*) in column 1 of comment lines, in order to distinguish FORTRAN 77 code from code of previous versions. ** (d) If a statement consists of an initial line and one or more continuation lines, only the last line should appear to terminate the statement legally. (For example, all lines but the last should terminate in an operator or comma.) * (e) Do not use FORTRAN key words as symbolic names. (f) Use blanks freely to improve the appearance of the code, especially to separate syntactic elements, e.g., on either side of equal signs, separators, and operators.
** (a) Use only the standard data types, avoiding reduced and extended precision data types as well as octal, hexadecimal and Hollerith unless essential for the application. The only standard types are real, integer (no size specification), logical, character, double precision, and complex. ** (b) Do not use abbreviations for .true and .false. ** (c) Use only the apostrophe (') to delimit character strings. * (d) Do not compare arithmetic expressions of different types. * (e) Do not use the operators .eq.i and .ne. with floating-point expressions as operands. ** (f) Use the relational operators .lt., .le., .gt., and .ge. only to compare character strings of equal length and character strings composed of either all letters or all digits. In all other cases, use the intrinsic functions llt, lle, lgt, and lge to compare character strings. ** (g) Do not use any other logical operator than the standard .not., .and., .or., .eqv. and .neqv., nor any abbreviated form. Do not use these operators on operands of any type other than logical. * (h) Arrays should be addressed such that their first indices vary the fastest and their last indices vary the slowest. This can avoid dramatic losses in efficiency on certain computers under certain conditions. ** (i) Subscript expressions should be of type integer only. ** (j) Array references should always contain the same number of subscripts as in the array declarations. ** (k) All common block names should be different from all subprogram names.
** (a) Do not override the FORTRAN type defaults for real and integer variables, constants, or functions. ** (b) Use mnemonic names. ** (c) Array subscripts should not assume values outside the lower and upper bounds of the declared dimensions. ** (d) Array references should always contain the same number of subscripts as in the array declaration. Also array references should not assume values outside the lower and upper bounds of the declared dimensions. (e) In mixed mode expressions and assignments, the type conversions should be written explicitly where this helps readability. ** (f) Statement numbers should be in ascending order. ** (g) Statement numbers should be right-adjusted.
(a) Limit the use of include files to define symbolic constants. On systems that do not allow include files, a preprocessor will be required to insert the include file into the source code. ** (b) Make as much use as possible of symbolic constants (parameter statements) for true constants. Use only the standard form of this statement: PARAMETER (PI=22./7., ONE=1.0) In particular, do not place function calls inside constant expressions in parameter statements. (c) Do not combine variable initialization with type declarations in one statement as is allowed by many compilers. * (d) Where data statements are used for initialization of common variables, use a block data subroutine. The method by which block data is loaded is system dependent and must be understood on a given processor. Be careful: When used in a library, some systems require explicit linking of the block data subroutine. * (e) Initialize all variables. Do not assume machine default value assignments. Do not initialize variables of one type with values of another (except possibly a single-precision floating- point variable with a double-precision constant to allow easy type promotion). ** (f) Use "implicit undefined (a - z)" statement to ensure all variables are declared. The syntax of this statement may vary on different systems.
** (a) Do-loop control parameters should be of type integer only. ** (b) Do not use nonstandard control constructs such as do...while. ** (c) Do not pass control into a do-loop, if-block, or else-clause other than by the normal initial statement.
** (a) Each do-loop should terminate on a separate continue statement. The body of the loop should be indented. * (b) The block-if should be used in preference to the arithmetic or logical-if. The body should be indented (see previous item). * (c) Avoid the use of the stop statement. (d) Use gotos only to implement control structures not provided by FORTRAN. Thoroughly document any use of gotos.
** (a) Main programs should always begin with the statement: PROGRAM name which should have no associated parameter list. ** (b) Use only those intrinsic functions which appear in the standard (and are indicated as such in most compiler manuals). Do not call host system services directly. (c) Note that the values returned by char and ichar are processor dependent. If this is likely to lead to a portability problem, a solution should be adopted in which a portable lookup table of values is implemented. * (d) Declare in an external statement all external functions. ** (e) Functions should not alter any of their arguments, nor any common variable, nor perform I/O, nor have any other side effect. (f) Place double precision and complex variables at the beginning of any common block in which they appear. * (g) Avoid the use of the equivalence statement, especially for variables of different types. ** (h) Do not mix variables of type character with variables of other types in common blocks. ** (i) Do not pass as arguments any variables which are contained in a common block referenced by both the calling and the called routines. (j) Use the save declaration where appropriate, as this might be required on certain processors.
(a) Statement functions should be contained between comment lines in a manner which makes clear that they are not the first executable statements. (b) The names of formal parameters of statement functions should not occur elsewhere in the same subprogram. * (c) Do not use an entry in a function subprogram. * (d) Terminate all subprograms by an end statement rather than a return. ** (e) Throughout a complete program, all end statements should bear the same label (or none). ** (f) Do not define external functions having the same name as intrinsic functions. (g) Use the alternate return facility only for exception handling. (h) Declare variables and arrays in the order: those used as formal arguments, those appearing in common blocks, those used only in the subprogram itself. Within the classifications, explicitly declare all variables in order of decreasing data size. * (i) Avoid the dimension statement; use type declarations including dimension declarations, e.g., real a(100), b(10). ** (j) An array in a common block should have its dimensions declared in the common statement. ** (k) A common statement should define only one common block; a common block should be defined in a single common statement. (l) The name of a common block should not occur otherwise as a name in any subprogram in which it is referenced. ** (m) Ensure that each common block is defined identically in all subprograms in which it appears. (n) Use the save declaration where appropriate because this might be required on certain processors. * (o) The arguments in a list should normally be ordered: input, output, control, external names, alternate returns. (p) Use the asterisk (*) notation to declare the last dimension of arrays passed as arguments if the extent in that dimension is unknown to the called routine. (q) Use the asterisk (*) notation to declare the length of character variables passed as arguments if their length is unknown to the called routine. * (r) Where equivalence statements are used, they should be grouped with the array declarations concerned. ** (s) Within a program module (group of subprograms), the subprograms should be ordered alphanumerically. * (t) Within a program unit, the common declarations should be ordered alphanumerically. (u) Use parentheses at all times to control evaluation order in expressions. ** (v) Do not use equivalence or common statements to assign two different data types to the same location in memory and then take advantage of how values are represented. (w) Data statements should appear after all other specification statements and before any statement function and executable statements.
(a) Do not use nonstandard I/O statements such as encode/decode (use internal files), define file (use open), namelist, punch, buffer in/buffer out and other asynchronous operations. (b) Read and write statements should have parameters which are either positional or keyword but not a mixture of the two. ** (c) Logical unit numbers should be symbolic constants or variables; they should never be asterisks (*) except for trivial I/O. ** (d) If a format specification is stored in an array, the array should be of type character. (e) Format specifiers should always be separated by a comma. ** (f) Do not make use of any numerical value of the iostat parameter; use only its sign.
(a) I/O statements on external files should contain the error recovery parameters err=, end=, iostat=, as appropriate. (b) Use write rather than print statements for nonterminal I/O. * (c) Where appropriate, group format statements at the end of each subprogram. Format statement labels should have their own numbering sequence.