Path: utzoo!attcan!uunet!mcsun!cernvax!julian
From: julian@cernvax.UUCP (julian bunn)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 77 Style Guide (long, REPOST)
Summary: Automatic Fortran 77 Guideline Checking
Message-ID: <2138@cernvax.UUCP>
Date: 3 Aug 90 12:07:02 GMT
References: <26B89BE1.4349@ics.uci.edu>
Organization: CERN, Geneva, Switzerland
Lines: 130

David Levine has recently posted an interesting set of Fortran 77
coding guidelines, itemized in 18 parts. In this posting I describe
which of Levine's guidelines may be automatically checked using
Floppy, a Fortran coding convention checker, the source of which
was posted to comp.sources.misc some weeks ago. I also describe
which guidelines are most commonly agreed to here at CERN, which
may also be checked by Floppy, and which do not appear in Levine's
list.


----------------------------------------------------------------------
The guideline headings and numbers below are as they appeared in David
Levine's posting.

IV. Program Units
    3) FUNCTIONs must not have side effects.
Floppy checks for I/O in functions.
    4) Reference external functions in an EXTERNAL statement.
Floppy checks this.
    5) Do not use alternate returns.  Every subprogram should have single
       entry and exit points.
Floppy checks for alternate returns.

V. Statement format
    2) Indicate a non-blank comment with an * in column 1.
Floppy will check for comment lines not beginning with "C"

VI. Statement labels
    2) Assign labels in ascending order.
Floppy will optionally re-order all statement labels in ascending order,
with fixed start and step size.
    3) Assign a separate sequence of labels to FORMAT labels that are grouped
       at the end of a subprogram.
Floppy will optionally do this, too.
    4) Right-adjust labels.
Floppy checks that labels do not begin in column 1.

VIII. Spacing
    2) Write keywords without embedded spaces, but surround keywords with
       spaces.
Floppy checks for embedded blanks, not only in keywords, but also in
variable names etc..
    8) Use indentation to reinforce control flow; each indent is 3 columns.
Floppy will optionally re-indent the source, the indent step for each level
being user-defined, between 1 and 5.

IX. Identifier Selection
    5) Do not use a keyword as an identifier.
Floppy checks this.
    6) Do not use a subprogram name as a COMMON block name.
Floppy checks this.

XI. Typing
    1) Use the following data types:
           CHARACTER[*n]
           COMPLEX
           DOUBLE PRECISION
           INTEGER*4
Floppy warns against INTEGER*4!
           INTEGER
           LOGICAL
           REAL
    2) Use DOUBLE PRECISION instead of REAL*8.
Floppy warns against REAL*8.
    6) Do not compare arithmetic expressions of different types; type convert
       explicitly.
Floppy checks for mixed mode expressions, e.g. A = B/I.

XII. Operators
    3) Compare unequal length character strings with LGE, LGT, LLE, and LLT.
Floppy checks this.

XV. Control structures
    4) Use STOP only for abnormal termination, and include the reason in the
       character string message.
Floppy checks that a STOP statement is immediately preceded by a WRITE.

XVIII. Input/Output
    2) Position a FORMAT statement immediately following its reference.
       Position FORMAT statements that are used more than once at the end of
       the subprogram.
Floppy will optionally move all FORMAT statement to the end of the module.
-----------------------------------------------------------------------------

Other guidelines in common use at CERN. (The numbers at the left refer
to the rule number in Floppy.)

IV. Program Units
  1   Avoid comment lines after end of module
  2   End all program modules with the END statement
  11  Avoid comment lines before module declaration
  12  Module names should not be the same as intrinsic names
  13  First statement in a module should be declaration
  14  Module should begin with at least 3 comment lines
  29  Avoid the use of ENTRY in FUNCTIONs
  36  Module names should all be different

V. Statement format
  40  Separate Statement Functions by comment lines
  41  No names in Statement Function definitions elsewhere

VI. Statement labels
  27  Statement labels should not begin in column 1

IX. Identifier Selection
  9   Integer variables should begin with I to N
  6   Variable names should be 6 or fewer characters long

XIII. Expressions
  16  No comment lines between continuation lines

XV. Control structures
  26  Avoid the use of PAUSE statements

XVI. Arguments
  38  Length of passed CHARACTER variables should be *
  44  Passed arguments should be dimensioned * in module

XVII. COMMON blocks
  3   Declared COMMON blocks must be used in the module
  4   COMPLEX and DOUBLEPRECISION variables at end of COMMON
  5   COMMON block definitions should not change between modules
  18  Avoid multiple COMMON definitions per line
  19  Do not dimension COMMON variables outside COMMON
  32  COMMON block names should not equal variable names

XVIII. Input/Output
  22  Avoid the use of PRINT statements (use WRITE)
  24  Avoid WRITE(* construction
  30  Avoid using I/O in FUNCTIONs