General Design Philosophies
The following guidelines have been extracted from a very large project
using Fortran 90. It involves many developers scattered across the
country and has an expected lifetime of 20 years. Code must be readable
by all current and future programmers. Note that the module IntrType
and its parameters sik and sdk are not standard to Fortran, just useful
constructs provided for the class. For those of you programming in
C, some specifics below will not apply, but you should follow the general
spirit of these guidelines.
Write all code so that anybody unfamiliar with the work can understand
it as quickly as possible. Remember that six months from now you
will be one of those people.
Start all subprograms with a header block of comments, clearly defining
the purpose of the subprogram, defining and delineating all input
arguments and output arguments, and giving your name and date the subprogram
Define all significant variables
Add comments describing the purpose of each key subsection of the subprogram
Structure code to make it as readable as possible
Use indentation (see below)
The main program should act as an outline with calls to subprograms which
actually perform desired operations.
All new variables will be explicitly typed, and all new routines will include
IMPLICIT NONE statements.
Implement a standard KIND representation for Integers and Reals
Always insert the line "USE IntrType"
after the MODULE statement, or for any subprograms that are not module
procedures, after the SUBROUTINE or FUNCTION statement. If IntrType
is declared at the module level, there is no need to include it within
the CONTAINed subroutines.
Begin all definitions of real variables with "REAL(sdk)"
Begin all definitions of integer variables with "INTEGER(sik)"
All use of real and integer constants should be implemented with
the _sdk and _sik kind type parameters
For example, use 2_sik instead of just 2, or 1.0e+10_sdk instead of 1.0d+10,
Do not use continuation lines inside of variable declaration
All dummy arguments and important local variables should be declared within
their own TYPE declaration declaration statements.
The INTENT of all dummy arguments should be declared in all new coding
Do not use bare END statements. Add the subprogram name (e.g. END
All Fortran statements, attributes, and logical operators in new coding
will be in all upper case.
REAL(sdk), POINTER, DIMENSION(:,:) :: a, aa
IF ( i.GT.j ) THEN
Underscores should not be used in any names
Variable names will be long enough to be self-documenting, within reason,
with a suggested limit of 15 characters
All new variable names will have the first letter of each element capitalized
except the first, as in pipeData.
All derived type names will end in "T", as in pipeDataT.
Module and subprogram names will begin with a capitalized letter, but don't
change old subprogram names.
File and procedure names should be no more than 12 characters long
All coding will be structured, with an indentation level of three spaces.
DO i = 1,n
DO j = 1,n
IF (i.gt.j) THEN
a(i,j) = - aa(j,i)
a(i,j) = aa(i,j)
Use IF-THEN-ENDIF instead of IF (condition) statement
"GOTO" statements will be used sparingly, if at all. Instead, programmers
should use IF-THEN-ELSE, SELECT CASE, CYCLE, EXIT, and internal subprograms
Use standard F90 free format code style with the following exceptions:
a limit of 80 columns per line:
Comments lines are indicated with a "!" in column 1.
Comments that serve to delineate. summarize, and/or clarify larger multistep
algorithms should be indented one or two spaces
Comments that serve to clarify the intent of and/or summarize small blocks
of code should be given the same indentation level as that code
Comments should be offset by at least one blank line from the previous
Never place a comment at the end of a continued line (illegal Fortran)
Where practical End-of-line comments should be used to define variables
INTEGER(sik) :: height = 0.0_sdk ! height of the
Source code should generally start in column 7. Columns 1-6 are to
be reserved for statement labels. This does not apply to comments
and MODULE statements.
Do not surround your coding with your initials
Never use COMMON. Use a MODULE and corresponding USE instead
Never use EQUIVALENCE. Use POINTERs instead
All code must be standard F90 - no use of non-standard compiler extensions
or preprocessor definitions are allowed
If available in the compiler, all code should be developed with strict
F90 standards checking and array bounds checking turn on. Also, compiler
flags should be engaged which check for any unused variables and uninitialized
variables. If any unused variables are located in a routine that
a developer touches, then he or she should remove them.
If a new subroutine is added to the code outside the scope of a MODULE
statement, then an explicit interface to that routine should be created.
This allows the compiler to handle checking of the argument lists at compile