This document describes the programming and documentation standards to be used by the Numerical Analysis Group of the Delft University of Technology, Faculty of Technical Mathematics and Informatics. All software made by the group should satisfy the standards described in this document. These standards do not only contain rules for the mere programming but also strict rules for the layout of source codes. This includes requirements about the comments to be used. Besides that the documentation of all software developed is treated.
Starting point for this document is the demand that programs and subroutines made, must be such that maintenance in the future is possible without disproportionate efforts. This implies a large discipline in the development, with possibly a larger effort than when less restrictive documentation demands are required. However, the cost of maintenance may be considerably lower and the reuse of code may depend on it. Besides that, the search for errors may be largely simplified.
Consequence of these requirements is that "neat programming structures" are used as much as possible. The internal documentation of the subroutines must be such that the tracing of errors is possible, using only the source code and not many other documents. Hence the description of the algorithms used must be contained in the source code. In some exceptional cases it may be impossible to describe the algorithm in the source code. In that case it is necessary that the method used is described in a commonly available document. The source code should refer to this document. Specific examples are the description of a data structure, the description of a discretization, the incorporation of boundary conditions and the type of physical modelling used. The separate documents to which the source code refers, must contain the complete details. It is in general not sufficient to refer to for example a PHD thesis with specific page number.
The reason to include the description of the methods and algorithms in the source code is only practical. If source codes are changed because of the improvement of some bug, it is common practice that the adaptation of the documents is neglected. Documentation in the source code will be updated more easily.
The use of a standard layout improves the readability of documents and moreover, makes it possible to use tools for the checking of the layout as well as help tools to generate a part of the layout.
Two of the requirements with respect to the source code, the use of a pseudo code and the explicit declaration of FORTRAN variables, may seem overdone. However, the reason to introduce the pseudo code is to make the source code self-contained. Explicit declarations makes it easier to detect typing errors by the compiler. Besides that, the programmer will be more aware of the variables he is using and, as a consequence, must describe. Another consequence is that the user is more naturally inclined to limit the number of local variables.
In Chapter 2 the general FORTRAN-77 standard is described
including the use of non-available control statements.
Chapter 3 describes the layout of FORTRAN modules including a
simple example.
In Chapter 4 an overview of BLAS subroutines is given. The use
of these subroutines is recommended as long as FORTRAN 77 is applied, since
on a number of computers these subroutines have been programmed such that
they deliver an optimal code.
Chapter 5 describes some tools to check the FORTRAN sources and
even tools that automatically generate a part of the comment block. These
tools are based on FORCHECK, a FORTRAN checker designed by Leiden University.
In Chapter 
some rules about the documentation of the software
developed are formulated. Following these rules makes the documentation more
uniform and moreover, makes it possible to incorporate the documentation
in modern viewing environments like hypertex.