In the world of scientific and engineering computing, applications must often take advantage of all the processing power the system is capable of providing. With the advent of low-cost computers with multiple processing cores, writing programs that employ parallel processing has become common.

Modern computers operate in the digital domain, yet users wish to simulate or control physical processes, which are usually continuous, or analog, in nature. The conversion between the two domains is necessarily imprecise. The closer the digital process can model the real-world one, the better the result.

A numerical model must be fine-grained enough to accurately model the process, yet it must not be too fine, or resource requirements such as CPU utilization and main memory space will be exceeded. A practical choice must often be made between precision of results and the ability to produce results in a reasonable time frame, if at all.

When faced with the requirement to speed up a computation, it is natural to consider parallel processing as a solution. At its inception, Fortran was designed in terms of a scalar processor model. That is, only a single thread of control is present, and code is executed in a serial fashion. However, as computers have evolved, many features have been added to the language that can be executed in parallel. These parallel capabilities are built in. Their use depends on the hardware available and the compiler.

Over the years, the Fortran standards committee has striven to keep each new standard backward-compatible with previous releases. Fortran is one of the oldest high-level languages; much old code is still in use. The committee has admirably succeeded, and programmers have known that they could continue to write programs that contained old features and that they could add features of the new standards whenever it was convenient, useful, or appropriate. Each new standard has marked only a few old features as “obsolescent,” defined as “A feature that is considered redundant but that is still in frequent use.” Those so marked in one standard may be “deleted” in a subsequent one. The standard describes a “deleted” feature as “A feature in a previous Fortran standard that is considered to have been redundant and largely unused.” This chapter describes many of these old features and the new ones provided by the modern Fortran standards (meaning from Fortran 90 and on) that you can use to replace them. We note the status of the each old feature. For further details, see the appropriate language standard: Fortran 90, Reference [40]; Fortran 95: Reference [42]; Fortran 2003, Reference [39]; and Fortran 2008, Reference [43].

Statements

Replace common blocks with modules.

In FORTRAN 66 and FORTRAN 77, programmers stored global data in common blocks. A program could have one unnamed common block and any number of named blocks.

Files

Place each program unit in a separate file.

Program units in Fortran are the main program, external subroutines, modules, and submodules. Placing each unit in a separate file makes the program easier to maintain. Shorter files tend to compile faster. You can locate different program components in files more easily. When a team of programmers is collaborating on a project, smaller files make it less likely that the work of one programmer will conflict with that of others.

It is crucial that you place submodules in files separate from their parent modules. Doing so prevents “compilation cascade,” a phenomena where a change in the implementation of a subprogram needlessly causes the recompilation of other program units (see Rule 124).

Whenever possible, use the module name, the type name, the subprogram name, or the program name as the file name.

This rule makes it easier to maintain programs. This is especially true if you code in conformance to Rule 133 and place each derived type in its own module, and you also choose to use either a prefix or suffix attached to a common base name when naming derived types and the modules that contain them. In that case, name the file according to the base name. For instance, you might have a type called pixel_t defined in module pixel_mod, and you can name the file pixel.f03 (see Section 4.2).

Use Fortran's C interoperability capabilities to interact with C programs.

Due to the enormous popularity of the C programming language (References [46], [38], and [28]), many Fortran programmers need to be able call routines written in C, or written to conform to C calling conventions. Likewise, it is often useful for C programmers to call routines written in Fortran. Beginning with Fortran 2003, there is a new and standard mechanism to allow easier and more portable interfacing between Fortran and C.

Here are some of the topics that must be considered when code written in Fortran accesses that written in C and vice versa:

• The mapping of built-in data types between Fortran and C.

• The mapping of pointers.

• The mapping between Fortran derived types and C structs.

• The mapping of global variables.

• The internal calling sequence mechanisms for passing actual arguments and function return values during procedure calls.

• The mapping of external names between Fortran and C and invocation of functions and procedures.

The next sections present details of these various points. The first deals with the mapping of the basic data types. Using these types, the second section presents the calling mechanism between the two, including mapping of external names; we present a short example. The sections that follow continue presenting the mapping of other types of entities, pointers, global data, and so on, also with short examples.

Audience

We wrote this book for anyone who writes programs using Fortran. We think it will be useful for the following categories of programmers:

• Those who are learning Fortran from scratch and want to start on the right foot.

• Those who are familiar with pre-modern FORTRAN (up to FORTAN 77) and would like to learn some of the new concepts and techniques of modern Fortran (Fortran 90 to Fortran 2008).

• Those who have advanced knowledge of Fortran, have experimented with various styles, and are open to new ways to improve their programs.

• Those who have experience with other languages, who know the importance of good coding style and who want to apply it to their Fortran code.

• Those who want to create coding guidelines for teams of programmers, or establish a good style for a project.

General Considerations

The past four revisions of the Fortran Standard comprise alternating major and minor revisions, Fortran 90 and Fortran 2003 being the former, Fortran 95 and Fortran 2008 the latter. This book concentrates primarily on Fortran 2003. We present Fortran 90/95 methods and note where the techniques and methods of Fortran 2003 supercede them. Fortran 2008 capabilities are described, but to a lesser extent.

Each programmer will judge the importance of the new features of the language based on his or her experience and needs. The new C Interoperability may be very important to a programmer who often needs to build an application written in both languages.

Write programs that are clear to both the reader and the compiler.

The first and foremost general principle of programming is clarity. From clarity comes the ability to test, to reuse, and to audit. One simple test is whether you believe you will be able to understand the code if you come back to it a year later.

Of course, you write programs to have the computer calculate something for you. And you know that the computer must be told exactly what to compute. Your program must completely and correctly specify what is to be computed.

If you are making a numerical calculation, you likely have some consideration for the efficiency of your calculation. The best way to gain efficiency is to first choose an efficient algorithm and then to write simple, clear, and logical code to implement it. Compared with more complex code, it is easier to understand and easier for the compiler to optimize.

In addition to writing code for the computer, you are also writing code for humans, yourself included. The purpose of the calculations and the methods used to do so must be clear.

To achieve these goals, write code that is as simple as possible. Use white space to aid your eye in following the calculation specified by the source code. Comment what cannot be understood from the code itself. The rules in this book follow from these ideas.

Until the advent of modern Fortran, the language could be classified as a strictly procedural one, built from subroutines and functions. A procedural program could be thought of as a series of calls to these procedures in which the desired computations are performed. Object-oriented programming, on the other hand, can be thought of as the interaction of independent entities, whereby the computations are carried out by means of messages sent and received by procedures (methods) bound to the entities (see Reference [8]).

Object-oriented programming (OOP) is a paradigm for programming that emphasizes the construction of objects that group related data. The objects are grouped with associated procedures and placed into a program unit, the module beginning with Fortran 90. Fortran 90 provided a limited capability for OOP, often referred to as “object-based” programming. Fortran 2003 provides the additional features that allow a programmer to program using object-oriented techniques. Some of the key features of OOP are (a) entities are constructed as objects. All objects are “instances” of what is commonly referred to as a “class,” which Fortran 90 introduced as “derived types.” These types define templates for the type data and its procedures. The placing of data in derived types is called “encapsulation.” (b) The procedures are referred to as “methods.” Execution of a program is carried out by objects communicating with each other by invoking the methods of other objects. This process is called “sending and receiving messages.”

Source Form

Always use free source form.

Fortran 90 introduced free source form. We recommend that it always be used in new code. Free source form offers a number of advantages over the older fixed source form code:

• Free source form is more compatible with modern interactive input devices than fixed form. The maximum line length is 132 characters, compared to the older limit of 72 characters. This reduces the possibility of text exceeding the limit, which could lead the compiler to misinterpret names.

• Line continuations in free form are performed by using a trailing ampersand character, &, rather than entering a character in column 6 of the following line. As an additional visual reminder and safeguard, a leading ampersand, placed in any column, is also allowed to precede the remaining source code.

• In fixed source form, the first six columns are reserved for statement labels, with column 1 also used to indicate comment lines. In modern code, using structured control statements, statement labels are rare. The first five columns are therefore wasted because they are rarely used. These last two features, combined with the next, provide much greater flexibility laying out the code.

• […]

The first section in this chapter explains the concept of “kinds” in Fortran. The second section presents several guidelines for using floating-point numbers in the context of performing numerical calculations using a representation that is by nature inexact. The third section presents some aspects of the floating-point exception handling that are now part of modern Fortran. Finally, in the fourth section we present some of the bit manipulation features.

The Concept of KIND

Modern Fortran characterizes the sizes and characteristics of integers, floating-point numbers and other data types as different kinds, and parameterizes them by kind type parameter values. For example, the Fortran processor will almost certainly provide a kind type parameter that corresponds to a four byte real. For one Fortran processor, the kind type parameter value may be 4, corresponding to the number of bytes; but, for a second processor, it could be 1, corresponding to the lowest precision available. The processor may also provide kind type parameters that correspond to single-byte, two-byte, and eight-byte integers.

The standard requires the processor provide at least one integer type. Similarly, two real kinds must be available. The default real kind is the less precise of the two. Normally, the default real will correspond to “single precision,” and the additional required kind to “double precision.” Thus, a processor may support several sizes of integers, each with a different kind type parameter value, and likewise for reals.

A common requirement when writing code is the ability to use the identical, or nearly identical, code for different data types. In the case of the public domain LAPACK linear algebra library (see Reference [5]), for instance, procedures support much the same set of operations for each of real, double precision, and complex data types. For example, the real version of a matrix operation routine might be identical to the complex version, except for a few details, primarily:

• The data type of the dummy arguments.

• The data type of function return values.

• The data type of localized temporary variables.

• Numeric constants (e.g., 1.0 vs (1.0,0.0)).

In addition to the data type, the kind and rank of arguments may also differ. A routine that processes real data may be identical to its double precision counterpart, thereby making the kinds different. And often routines accepting scalar arguments may need to be expanded to accept array arguments.

A number of techniques are used to make the job of generic programming easier and less error prone than simply replicating and hand-editing code. These techniques can be divided into three general methodologies: reducing the need to replicate code, reducing the number of code changes required to replicate code, and finally, automating the replication of code. The specific techniques we discuss are:

• Use parameterized derived types to avoid replication based on kind and len.

• Create and use generic names for procedures with interface blocks.

• […]

Standards Conformance

Always write standard-conforming code.

Adherence to no other guideline in this book will make your code more portable than adhering to this one. Over the years, compiler vendors and others have added numerous nonstandard extensions to the language. There is no guarantee that every compiler will support them or that any given compiler will continue to do so in the future.

When you write code that conforms to the standard, you can expect and demand that a “standard-conforming” compiler will successfully compile it. If it cannot, you have a good indication that either your code is in error, that it does not conform to the standard, or that there is a problem with the compiler itself. Most compilers can provide warning messages when encountering nonstandard code. If possible, do not depend on a single compiler as a reference. Compiling code through several different vendors' compilers can often expose additional errors. (See also Rule 4 and Section 15.3.)

Do not rely on compiler switches that change code semantics.

Many compiler vendors have added switches to their compiler directives that provide a capability that the programmer must otherwise provide by writing code. Some compilers, for example, have a switch that will automatically initialize all variables or change the default kinds of variables. Others have switches that remove the necessity for explicitly including the implicit none statement in every program unit. You should not use these; they make your code nonportable.