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 was created.
• 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, etc
• 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 Output)
• 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)
            ELSE
               a(i,j) = aa(i,j)
            ENDIF
         ENDDO
      ENDDO

• 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 as appropriate
• Use standard F90 free format code style with the following exceptions:
• a limit of 80 columns per line:
• 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.
• 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 F90 statement.
• 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

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