General requirements

• The code must be written according the ANSI-FORTRAN 77 norm with the exception of:
  complex 16;
  implicit none;
  use of small letters instead of capitals;
  include;
  restriction to six characters for a variable.
• The transfer of parameters between subroutines and function should be done by the parameter list or by named common. The use of commons should be restricted to special purpose commons only, for example to define global machine constants.
  Not only the length of named commons must be the same in all subroutines and main programs, also its subdivision into variables. Furthermore each variable in the named common must be described.
  It is advised to include commons by means of an include statement. However, as soon as source code is exported to other computers it may be necessary to replace the include statements by the actual code. As a consequence changing of the number of variables in the common may be complicated once an export has been performed. A way to overcome this problem partially is to extend each common with one or more dummy arrays that may be replaced by actual variables in future extensions.
  It is a good practice to concentrate all commons in one separate directory. For example in the ISNaS code all commons are stored in the directory isnas/common.
  To include commons in your source use:

        include 'name_of_common'
  

  where 'name_of_common' is the actual name of the common. In ISNaS it suffices to give the actual name, since the link command includes the correct directory.
• The source code must be subdivided into segments, which must be surveyable. A general rule might be that the actual source code may not exceed 100 lines. However, in a number of clear sequential commands the actual number of lines may be larger.
• The first line of each module must be a program, subroutine or function statement.
  The use of a program statement for a main program is obligatory.
  This first line is followed by comment statements according to the rules described in Chapter 3.
• The use of block data is not permitted, since the incorporation in libraries may be difficult.
• Avoid the use of mixed mode expressions (single precision/ double precision) as much as possible. It may cause unwanted side effects.
• All variables in a program or subroutine must be declared explicitly. The first declaration will always be the statement:
  implicit none
  If the actual computer does not recognize this statement it may be replaced by
  implicit character 1 (A-Z)
  At export of the code the implicit none statement is outcommented by cimp in columns 1 to 4.
  In order to prevent unnecessary confusion it is recommended to satisfy the implicit FORTRAN standard for naming conventions. Hence names of integers should start with one of the letters I to N, complex variables should start with a C or a Z and all other letters are restricted to (double precision) reals.
• Never use a dimension statement to declare an array, but always use the explicit type declaration.

   
  Hence: 		not  		   DIMENSION IARRAY (100)
  
         		but  		   INTEGER IARRAY (100)
  
  

  Never use real expressions in array dimensions. The length of arrays in common blocks must be declared explicitly in those commons.
• The end of a do-loop may be either indicated by a continue statement or by end do. Since enddo is allowed in FORTRAN 90 this last possibility is recommended. In case of nested do-loop it is necessary to end each loop with its own continue or enddo statement.
• The use of capitals interchanged by small letters may improve the readability although it is not standard FORTRAN. In general small letters are recommended.
• Names have a meaning inside a subroutine only. They must have a logical structure (the name must imply the function). All names to be used must have been inspired by the english meaning of the function.
  The length of names of subroutines and functions is restricted to 8. This is not standard FORTRAN 77, which allows only 6 characters, but most present day compilers are able to distinguish longer names. The reason to restrict ourselves to 8 characters is that under DOS the names of files are restricted to 8 characters only. External delivered subroutines, like for example PVM subroutines may of course have more characters. The number of characters in names of variables is not restricted. However, in order to get a nice lay-out in the comment block it is recommended that this number does not exceed ten.
  It is highly recommended to use unique variable names for all software. Such unique names make the application of comment generating tools sensible, and also improve the readability. We refer to Chapter 5 which describes some tools to generate the comment block. These tools make use of standard dictionaries with names of variables and subroutines.
• Make frequently use of spaces, blank lines and comment statements to improve the readability of the source code.
• If possible avoid the use of the option in the declaration of arrays. If the actual length is used as parameter in the parameter list, it is more easy to use array bound checkers and debuggers.
• Use more-dimensional arrays if it matches the logical structure, unless it implies a large extension of the memory necessary. Do not use help variables in order to make the program more efficiently. Modern compilers are better capable of constructing an optimal code, and moreover, these extra variables usually do not improve the readability.
• Develop the code such that it may be used on a vector machine. This means that clean do-loops should be used and that if then else constructions, should be placed outside the do-loops. See also Section 2.8 for more details on how to optimize the code for vector machines. Even if you do not intend to use a vector computer, following these rules in general may also improve the performance at scalar computers.
• Use the parameter statement to initialize constants.
• Statement labels should satisfy the following requirements:
  • Statement labels may only be used in continue and format statements, or to simulate a while loop.
  • Statement labels must be used in increasing sequence.
• Use the parameter statement to initialize constants.
• Character strings should satisfy the following requirements:
  • A string supplied through the parameter list must be variably dimensioned in that subroutine. Hence:
    CHARACTER .
  • The length of a string is not given through the parameter list. It may be detected by the FORTRAN intrinsic function "LEN".
  • Strings may not be used as operands in relational operators (.LT., .LE., .EQ., .NE., .GE.). The FORTRAN functions LGE, LGT, LLE, LLT, however, are allowed.
  • The functions ICHAR and CHAR may not be used in such a way that the code depends on the underlying character set (ASCII, EBCDIC).
• Every variable in a subroutine must be initialized. Never assume that the compiler automatically initializes all variables to zero. In fact many compilers do not have this habit. Use the concept of keeping local variables in a subroutine for a next call, as little as possible. If you need this option, a save statement is necessary.
• Do not use the following FORTRAN statements:
  • statement functions (function in one line within another subroutine)
  • assigned goto
  • arithmetic if (IF .... label1, label2, label3)
  • equivalence
  • entry
  • err= and end= in read commands (use iostat specifier)
  • pause
  • more than one entry or exit for a module (ENTRY, alternate RETURN)
  • jump to ENDIF from outside IF-block
  • non-integer index in a do-loop
  • the H edit descriptor
  • RETURN
• Always use the generic name in case of intrinsic functions, e.g. never cabs or dabs but always abs.
• A STOP may only be used in:
  • an error subroutine after the printing of fatal error
  • an explicit closing subroutine
  In SEPRAN subroutine INSTOP should be called instead of giving stop.
  In ISNaS subroutine ISSTOP should be called instead of giving stop.
• Apply BLAS subroutines to perform simple linear algebra operations, if possible and useful. On many vector computers very efficient implementations of these subroutines are available. So use of these subroutines may increase the performance. For a description of the BLAS subroutines we refer to Chapter 4.
• Never use a GOTO statement except to simulate a while according to the rules in Section 2.2
• Never use blank common yourself. Blank common has been reserved for memory management.
• Output or results should only be written to backing storage if there is a very good reason. i/o is very expensive and should be avoided as much as possible. In many cases it is much cheaper to store computed results in an array or even to recompute the results if the amount of available memory is too small.
• In case of multidimensional arrays applied in nested do-loops it is advised to use the inner loop for the first index. This may increase the efficiency at vector computers.