Coding Standards/Style Guides Wanted 
Author Message
 Coding Standards/Style Guides Wanted

We're in the process of defining Coding Standards for Ada, Pascal, fortran, C
and Assembler. We've been fortunate with Ada and C, since there are published
standards and coding style guides that we could adapt for our purposes. It is
more difficult with Pascal, FORTRAN, and Assembler since there are so many
dialects. We decided to use the ANSI standard definition of each language, and
write our standards without the commonly-used language extensions. For example,
we had to omit the "!" end of line comment delimiter in FORTRAN since it's an
extension to the language.

Is anyone aware of coding standards or style guides for FORTRAN, Pascal, or
Assembler? Please reply via this news group rather than direct mail.


John J. Cupak, Jr., CCP       Lockheed Net   : cupak::mervax

95 C{*filter*}Street / NCA15-221   CompuServe     : 72411,3176
Nashua, NH 03061-0868         America Online : jcupak

Fri, 31 Dec 1993 21:31:25 GMT  
 Coding Standards/Style Guides Wanted

1) I've always liked "The Elements of Programming Style", Kernighan
and Plauger, McGraw-Hill.  Not exactly what you want, probably, but
see 2) below.

2) You might not want precisely defined styles to follow.  What's the
point of a coding style?  To make the code easier to read, correct?
Ok, why make it easier to read?  To make it easier to maintain.  But,
if programmers have to go to some effort to follow a certain style,
they'll be frustrated and it won't be easy to maintain, *even though
it's a quite readable style*.

What I prefer is this:  code in a simple style using GNU Emacs.  Use
the language mode so the *editor* produces the common style, not the
programmer.  The editor can handle indenting, comment spacing and so
on, leaving the programmer to do the harder stuff.
Ralph Finch                     916-445-0088

Any opinions expressed are my own; they do not represent the DWR

Sun, 16 Jan 1994 01:14:39 GMT  
 Coding Standards/Style Guides Wanted

>Is anyone aware of coding standards or style guides for FORTRAN ...

Here is something I picked on the net sometime ago. I have cut some stuff in
it, mainly acknowlegments etc... Maybe a more recent version in available from
the author ...

                         Fortran 77 Coding Guidelines

David L. Levine                                                    1 Dec 1989

I. Introduction

    The following guidelines are designed to encourage consistent coding
across projects and programmers.  Many arbitrary low-level decisions are made
during coding.  While many of these have no effect on the machine code, they
do affect the appearance of the code.  And, consistent practices enhance
productivity and reusability.  Project requirements, when applicable, take

    The goals of the guidelines are, in decreasing order of importance:

    1) understandability -- conveys the purpose of computations to the reader
    2) transportability -- between compilers on assorted modern operating
    3) maintainability -- can be readily enhanced
    4) efficiency -- execution speed

II. General
    1) Adhere to strict FORTRAN 77 as closely as possible, with the following
       a)  In addition to the standard character set (where the notation [0-9]
           indicates the numerals 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9)
                space $ ' ( ) * +  , - . / : =  [0-9] [A-Z]
           the following characters may be used:
                ! # & [a-z]
       b)  Identifier names may be up to 31 characters long (the first 6
           remain significant).
       c)  INCLUDE statements may be used.
       d)  INTEGER*4 may be used when INTEGER defaults to 2 bytes.
    2) Avoid compiler directives in code, especially if an equivalent
       compiler option is available.  If a compiler directive must be used,
       comment its effect and target machine, operating system, and compiler,
       with revision numbers.
    3) Use a consistent set of compiler options, or maintain a makefile or
       command procedure to enable reconstruction.  Suggested compiler
       options are listed in Appendix II.

III. Project Organization
    1) Use a standardized comment header at the top of every subprogram (see
       example in Appendix III).
    2) Group related subprograms into a module.  The module is assigned a
       unique name and is typically stored in one or more files in a single
       subdirectory on the file system.  If used, a single object library
       contains the code for all the module components.
    3) The first two letters of the routine and file name correspond to the
       module and the remaining four uniquely identify the routine.
       Additional characters may be used to create a more sensible name.

IV. Program Units
    1) Begin a main program with a PROGRAM statement.
    2) Order arguments as follows:  inputs, outputs, control, external names.
    3) FUNCTIONs must not have side effects.
    4) Reference external functions in an EXTERNAL statement.
    5) Do not use alternate returns.  Every subprogram should have single
       entry and exit points.

V. Statement format
    1) Use the standard source format (columns 1-5 for label, 6 for
       continuation, and 7-72 for statement).
    2) Indicate a non-blank comment with an * in column 1.
    3) Indicate a continuation with an & in column 6.
    4) Do not split a name across lines.
    5) Do not write more than one statement per line.

VI. Statement labels
    1) Assign a label only if necessary.
    2) Assign labels in ascending order.
    3) Assign a separate sequence of labels to FORMAT labels that are grouped
       at the end of a subprogram.
    4) Right-adjust labels.
    5) Do not use the label field of a continuation line.

VII. Capitalization
    1) Set keywords in all caps.
    2) Set symbolic names of constants (parameters) in all lower case.
    3) Set all other identifiers in initial caps with embedded words initial

VIII. Spacing
    1) Do not use tabs.
    2) Write keywords without embedded spaces, but surround keywords with
    3) Do not put space between and array name and its index, Array(I).
    4) Put one space between a subprogram name and its argument list, e.g.,
       Subr (Arg1, Arg2).
    5) Except in argument lists, put a space after an open parenthesis and
       before a close parenthesis.
    6) Put one space between arguments.
    7) Use spacing in equations to reveal operators and reinforce precedence.
    8) Use indentation to reinforce control flow; each indent is 3 columns.
    9) Use whitespace to enhance readability.

IX. Identifier Selection
    1) Start with letter [A-Z], follow with only letters or digits.
    2) Limit to 31 characters; distinguish with first 6.
    3) Choose an identifier to represent the entity being modeled.
    4) Explain the significance of each variable and array in comments.
    5) Do not use a keyword as an identifier.
    6) Do not use a subprogram name as a COMMON block name.
    7) Do not abbreviate .TRUE. or .FALSE.
    8) Delimit character strings with apostrophes.

X. Constants
    1) Use PARAMETERs to symbolically name all compile-time constants.
    2) Use only constant expressions to define PARAMETERs.

XI. Typing
    1) Use the following data types:
    2) Use DOUBLE PRECISION instead of REAL*8.
    3) Use INTEGER for integers that are always in the range of two-byte
       integers [-32768,32767]; then use a compiler option to select two or
       four byte storage.
    4) Declare all variables.  Use a compiler option to ensure declaration.
       If no such compiler option is available, setting the implicit type of
       all variables to a type that is not used in the program often snags
       undeclared variables.  An example is:  IMPLICIT COMPLEX*16 A-Z.
    5) Arrange identifiers in type declarations logically based on the
       entities which they describe.  Subprogram arguments may be declared in
       order of appearance in the argument list.  If there is no other
       obvious order, arrange alphabetically.
    6) Do not compare arithmetic expressions of different types; type convert

XII. Operators
    1) Do not use .EQ. and .NE. between floating point expressions.
    2) Use .GE. or .LE., as appropriate, instead of .EQ. when checking for a
       threshold crossing.
    3) Compare unequal length character strings with LGE, LGT, LLE, and LLT.
    4) Use only the logical operators .AND., .OR., .EQV., .NEQV., and .NOT.,
       and only use them on LOGICAL operands.

XIII. Expressions
    1) Surround low precedence operators with space.
    2) Split an expression across lines after an operator.
    3) Indent continuation lines.
    4) Consider the types of operands and their effects on the values of
       subexpressions, e.g., 8 / 3 * 3.0 is 6.0, not 8.0.
    5) Be careful with "exact" values of floating point expressions, e.g.,
       assigning 30.0 / 0.1 to an integer may define it as 299!

XIV. Arrays
    1) Declare array dimensions in the type declaration rather than in a
       separate DIMENSION statement.
    2) Use only INTEGER subscript expressions.
    3) Preferably operate on arrays such that the first indices vary fastest
       and the last vary slowest.
    4) Specify all subscripts in any array reference.
    5) Do not exceed the bounds of declared array dimensions.

XV. Control structures
    1) Use GOTO carefully.  See Appendix I for loop constructs.  Comments at
       the target of a GOTO listing possible 'come froms' are very helpful.
    2) Terminate or begin every loop with a distinct CONTINUE.
    3) Do not jump into the middle of a loop or conditional.
    4) Use STOP only for abnormal termination, and include the reason in the
       character string message.

XVI. Arguments
    1) Match the actual arguments in the caller to the formal arguments of
       the callee in both number and type.
    2) Do not repeat an actual argument in any call.
    3) All arguments to an intrinsic function must be of the same type.
    4) Do not pass a constant as an actual argument unless it is to an IN
       formal (see Appendix III for definition).

    1) Only place data in COMMON blocks if necessary.
    2) Place COMMON block definitions in INCLUDE files.
    3) SAVE all COMMON blocks.
    4) Do not mix CHARACTER and non-character types in a COMMON block.
    5) Do not pass as an argument any variable referenced in a COMMON block
       in both the calling and called subprograms.
    6) Initialize COMMON blocks only in BLOCK DATA subprograms.
    7) Compile BLOCK DATA subprograms with another program unit in which it
       is referred to with an EXTERNAL statement.
    8) Use EQUIVALENCE with care, and only to economize on storage; avoid
       aliasing and then only if well commented.

XVIII. Input/Output
    1) Use error recovery options END=, ERR=, and IOSTAT=, and handle all
       such conditions gracefully.
    2) Position a FORMAT statement immediately following its reference.
       Position FORMAT statements that are used more than once at the end of
       the subprogram.
    3) Use implied DO rather than DO loops.
    4) OPEN all files with STATUS = 'UNKNOWN' unless otherwise is required.

                         APPENDIX I.  Loop Constructs

    1) iterative

      DO 10 I = 1, iterations
         . . .

       Do not modify the loop variable.

    2) while

         . . .
         IF ( condition ) GOTO 20
         . . .
         GOTO 10

    3) do-while

read more »

Sun, 16 Jan 1994 05:10:21 GMT  
 [ 3 post ] 

 Relevant Pages 

1. Coding Standards/Style Guide Wanted

2. Coding Standards/Style Guide Wanted

3. Coding Standards/Style Guides Wanted

4. IDL Style Guide Wanted

5. Wanted: pretty printer for MIL-HDBK-1804 Ada Style Guide

6. VHDL Style Guide for Portable Synthesisable Code

7. Coding/style guide for F90

8. Coding Standards. was: a style question

9. Modula-2 Coding Style Standard

10. Verilog Coding Style Standard

11. PCSCHEME code wanted for creating standard graphics files

12. WANTED : F77 code with all standard statements.


Powered by phpBB® Forum Software