Fortran programs are used to design aircraft, ships, bridges, power plant, space craft, medical drugs ... Perhaps most importantly, they are used to model the Earth's climate and to inform the prediction of climate change. The engineers and scientists already know that the results they generate are about right. Man years of program development on expensive equipment are invested for the last few percent of accuracy which go beyond the engineer or scientist's intuition. The achievement of this last few percent depends on the quality of the code.

Three aspects of code quality are handled by FPT.

• Is the code well written? Is it well formatted, adequately commented, and are the variable names meaningful?

  • FPT automatically handles code layout and formatting. Please see the reference manual pages on code formatting.
  • FPT measures the number of comments and, more importantly, the number of words in comments. These are reported by the SHOW METRICS command.
  • Non-local names should be sufficiently long to be meaningful. FPT measures the average length of the names used for objects visible in multiple routines to provide a measure of meaningfulness.
  • Names visible in many different routines should be unique so that they cannot be confused with local names. FPT measures the proportion of the names used for non-local objects which are unique. Again, please see the Code Metrics page and the SHOW METRICS command for further description.

• Is the code fully tested? Do the tests exercise all of the code? Is the test suite well automated?

  • FPT provides tools for test coverage analysis. The tests show the proportion of the code exercised in a test, and facilities are provided to merge coverage data from different test runs.
  • The record / replay facility may be used to create automated test suites, particularly where there are manual inputs to a program, or where the program accesses a database.
  • The run-time trace facility may also be used to automate testing, and may be used to eliminate numerical drift from test runs where code is tested under different compilers or environments.

• Are there errors? The issue of coding errors is described below.

 
Errors in Microsyntax, Syntax and Semantics

When FPT reads a program it carries out a detailed syntactic and semantic analysis in the same way as a Fortran compiler. Diagnostics are reported, for example:

• If FPT is unable to analyse all or part of the syntax of a statement.

• If names are used inappropriately, for example, where a Fortran keyword is used to name a variable, or where the use of a name conflicts with its declaration.

• If expressions are constructed in such a way that there is a loss of precision.

• If the actual arguments passed to sub-programs cannot have the INTENT required by the sub-program code - e.g. where a constant is passed to a sub-program in an argument to which the sub-program writes a result.

These diagnostics are always issued unless they have been explicitly suppressed (See the SUPPRESS ERROR command).

Checks for Specific Classes of Error

Commands are available to check for specific classes of errors. Most of the checks may also be modified by filters which suppress reports of the less serious cases. The checks are:

• Sub-program Argument Check

  FPT checks that the actual arguments passed to sub-programs are consistent with the formal arguments in the sub-program declarations. The arguments must match in:

  • data type, i.e. INTEGER, REAL, COMPLEX, CHARACTER, Derived TYPE etc.;
  • data kind and size, e.g. REAL*4, REAL*8 etc.
  • intent, whether input, output, input and output, sub-program argument etc.;
  • protocol, whether passed by reference, value, address and length, descriptor etc.;
  • array shape. The array shapes must conform though they need not match exactly.

• Sub-program Argument INTENT Check

  FPT checks that the INTENT (if any) declared for a sub-program argument is consistent with the way in which the argument is used.

• Name Check

  If the same name is used for two or more objects in a program, FPT checks that the attributes of the objects are the same. In particular, checks are made for variables with the same name at different COMMON block addresses, and for Fortran parameters with the same names but different values in different routines. Note that these occurrences are not Fortran errors. However, they may indicate coding errors.

• Alignment Check

  A check is made for variables forced to mis-aligned addresses as a result of SEQUENCE DERIVED TYPE, COMMON block. STRUCTURE/MAP/UNION or EQUIVALENCE constructs.

• EQUIVALENCE Check

  Checks are made for:

  • Objects which are forced to the same COMMON block address without an explicit EQUIVALENCE statement.
  • Objects of different data types or kinds which are set at the same address by EQUIVALENCE statements.

• Check of DATA in COMMON

  A check is made that each COMMON block is initialised by DATA statements in at most only one program unit. This command detects a problem with the Linux, Unix and Windows default linkers. If a COMMON block is initialised in more than one BLOCK DATA or other program unit, these linkers overwrite all of the initialisations by the last one linked. All of the other initialisations are lost.

• Data Type Coercion Check

  Checks are made for the use of inappropriate data types in Fortran constructs. The most common to be encountered is the use of an integer variable in a context which requires a logical. Many compilers do not report this as an error.

• Array Bounds Check

  A check is made that all array indices are within the bounds of the array. Two checks are made. If the index is a constant, it is checked and an error is reported if it is out-of-bounds (Most compilers also make this check). If the index is a variable, the relevant assignments of the variable are identified. If the variable is expected to go out-of-bounds a warning is issued.

• Usage Check

  Checks are made for variables which are, or may be:

  • used before they are assigned;
  • assigned values which are never used;
  • declared but never used.

• Whole Array Assignment Check

  FPT checks for unsubscripted whole arrays which are assigned to scalar values across an equals sign. This is legal Fortran (Fortran 90 and Gould-SEL Extended Fortran 77) but is a common source of error.

• Program Flow Analysis

  A check is made for unreachable code.

• Ambiguous Flow Check

  FPT checks for cases where the program flow is ambiguous. This occurs when a statement contains two or more function invocations at equivalent levels of expression nesting. The Fortran standard explicitly states that the order of evaluation is undefined. This may lead to inconsistent results, and it makes comparison of program behaviour under different compilers difficult.

• Overloaded Assignment Check

  Fortran 90 (and later) allows the assignment of variables of derived types to be overloaded and to be carried out by user-defined subroutines. If no overload exists, the values of the types are copied directly. A problem exists that an error in exporting or declaring the overload may prevent it from taking place. This command checks that, where an overload exists, the assignment is always overloaded and is never made directly.

• Units Check

  FPT attempts to infer the units and dimensions of real variables, and to detect inconsistent uses. Please note that this command is experimental and forms part os a research project.

 
QA Auditing

In auditing, the objective is to assess the state of a code, not to change it. It is recommended that a standard test regime is set up in an fsp file with a chosen set of checks, and that this is applied to a number of projects to gain a comparative feel for code quality. The procedure for setting up projects and fsp files is described in "Running fpt" in the FPT Reference Manual. An example QA auditing file is described on the Metrics page.

QA Enforcement

If the intention is to enforce a QA regime and to remove errors, it is recommended that the project is set up in the same way as a software migration. This is essentially a migration from the original sources to a corrected code base. Please see the description of Migration in the FPT Reference Manual. We recommend setting up parallel original_source, modified_source and fpt_output directory structures as described there. FPT may then be used to reformat the code and to make some of the changes.