- list of files opened (and closed!)

 - assumptions, pre-requisites, limitations
   (eg such & such file must be open, or  crashes if given -ve values)

 - exactly how this code is compiled (maybe just point to the makefile)

and can usefully include:

 - usage example

 - error conditions (what errors this code detects and what it does then)

 - list of all common blocks

 - functions called from within this code

 - which programs call this code
 

Goto's (explicit and via error traps, such as in IO statements)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 - must never jump into a do loop
 
 - must never jump into an if block

 - should jump to a continue statement, and certainly not to the foot (last
   statement) of a DO or IF block
 

Indentation and block structure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Don't bother
  ... unless it is done consistently throughout

Use endif and enddo everywhere

Block structures similar to IF or DO blocks should be similarly indented.
 

Style
~~~~~
Code that could be needed any time after next week should be tidied up,
by removing diagnostics and any superceded code. If there is a need to
preserve a diagnositic or "can be tinkered to do anything" code, keep
that version as a separate version that is so labelled. The real code
should only perform the minimum task it is meant to do, and should be
bare of any code that is not directly involved in that task.
 

Modularity
~~~~~~~~~~
Every code file should contain code that does SOMETHING - (not just a couple
of lines that call yet another subroutine).

On the other hand, each subroutine should have a main purpose, and should
not be cluttered with code blocks which are doing discreet subtasks. Those
lumps should be removed to further subroutines!  One axiom is that a
single routine should fit on one page, so that you can view the thing as
a whole. This is a little extreme, but a worthy aim! Attempting to
achieve this forces you to package up subtasks into other subroutines -
and if that is done by deciding what is the real task and coding it in
a general way, then often those subroutines will be reusable in other programs.

For example, if a program is to compute the area of a polygon, but it
takes 10 lines to convert character string inputs into float numbers,
then those lines should probably go into a subroutine.