Nowadays there are myriad tools to select from if you develop and maintain software. Much is open source, but there are also many commercial tools available. The development and maintenance tools include:

1. ■ Compilers, linkers, and interactive debuggers

2. ■ Build tools to automatically compile the source code in the right order

3. ■ Integrated development environments

4. ■ Tools for static and dynamic analysis

5. ■ Version control systems

6. ■ Tools for source code documentation

This appendix describes some uses of these tools, but it does not provide a complete overview.

The Compiler

Since the Fortran 90 standard, the language has gained features that make it easier for the compiler to perform static and dynamic analysis:

1. ■ The implicit none statement (or equivalent compiler options) force the compiler to check that every variable is explicitly declared. This reduces the chance that typos inadvertently introduce bugs in the form of stray variables names into the program.

2. ■ By putting all routines in modules, you make sure the compiler checks the number and types of the arguments for subroutine and function calls. It also reduces name clashes when linking a large program, which uses many libraries.

3. ■ By using assumed-shape arrays instead of assumed-size, the compiler can insert runtime checks for array bounds. Moreover, you do not need to add separate arguments for the size of arrays anymore. This makes the call simpler and less error-prone.

Therefore, the compiler has become a much more powerful tool with respect to static and dynamic analysis.

The applications of Fortran span, very nearly, the whole period during which computers have been in general-purpose use. This is quite remarkable and, given the demise so many other high-level languages, it is quite difficult to know why. Possibly the original design concepts of John Backus – ease of use and efficiency of execution – have been two major factors. Another might be the devotion of Fortran's user community, who labor to keep it abreast of developments in programming techniques and to adapt it to ever-more demanding requirements.

Despite all the predictions, over several decades, that Fortran is about to become extinct, the language has shown itself to be remarkably resilient. Furthermore, over the last few years, it has been subject to new rounds of standardization, and the latest standard, Fortran 2008, should again extend the language's life. Against this background, it is very regrettable that old versions of Fortran live on, both in the form of antiquated courses given by incorrigible teachers and also as an outmoded concept in the minds of its detractors. After all, modern Fortran is a procedural, imperative, and compiled language with a syntax well suited to a direct representation of mathematical formulae. Its individual procedures may be compiled separately or grouped into modules, either way allowing the convenient construction of very large programs and procedure libraries. The language contains features for array processing, abstract data types, dynamic data structures, object-oriented programming, and parallel processing.

Acknowledgments

The authors thank the Numerical Algorithms Group Ltd. (NAG) who provided us with copies of their excellent compiler with which we could test our code. In particular, thanks go to Mr. Malcolm Cohen, Mr. Rob Holmes, Mr. Ian Hounam, Mr. Rob Meyer, Mr. Mike Modica, and Mr. John Morrissey.

The Portland Group provided us with a copy of their compiler. Special thanks go to Ms. Laura Gibon for arranging that.

We thank Mr. Art Lazanoff for the use of his network server system for our CVS repository.

We thank Mr. Dan Nagle who offered vigorous criticism and some good suggestions.

The following persons read over the manuscript; to them we owe our gratitude: Dr. Greg Brown, Dr. Charles Crawford, Mr. Ryan O'Kuinghttons, and Dr. James Hlavka.

Thanks go to Ms. Stacy L. Castillo at the IBM Corporate Archives for arranging permission to use the material for the frontispiece.

It was a great pleasure to work with our editors at Cambridge University Press: Ms. Heather Bergman, Ms. Lauren Cowles and Mr. David Jou.

Typographical Conventions

The following typographical conventions are used in this book:

1. • medium-weight serif font – normal text

2. This sentence is written in the font used for normal text.

3. • bold italicized serif font – rules

4. • medium-weight sans serif font – computer code

5. • bold sans serif font – Fortran keywords

6. […]

This appendix provides the user with a complete list of all the guidelines contained in the book. They are listed in the order of their appearance and grouped by chapter. The page on which each rule can be found in parentheses following the rule.

Chapter 2. General Principles

1. 1. Write programs that are clear to both the reader and the compiler. (3)

2. 2. Write programs that can be efficiently tested. (4)

3. 3. Write programs that will scale to different problem sizes. (5)

4. 4. Write code that can be reused. (6)

5. 5. Document all code changes, keeping a history of all code revisions. (6)

Chapter 3. Formatting Conventions

1. 6. Always use free source form. (9)

2. 7. Adopt and use a consistent set of rules for case. (10)

1. 7.1 Use lowercase throughout. (11)

2. 7.2 Capitalize the names of all user-written procedures. (11)

3. 7.3 Write all named constants using uppercase letters. (12)

4. 7.4 Begin the name of all data entities using a lowercase letter. (12)

1. 8. Use a consistent number of spaces when indenting code. (13)

2. 9. Increase the indentation of the source code every time the data scope changes. (13)

3. 10. Indent the block of code statements within all control constructs. (14)

4. […]

Modules, Procedures, and Types

Use detailed names for data objects whose scope is global, less detailed names for those whose scope is a module, and simple but clear names for those whose scope is a single procedure.

Symbolic names are used in many places. At the outermost level are the names of modules, the main program, and external procedure program units. Within the confines of a program unit are derived-type definitions, named constants, and variables. In addition, there are also internal procedures and interface blocks.

Within individual procedures, there are statement labels for control flow and I/O purposes.

Generally, the more global the name, the longer and more descriptive it should be. And, likewise, the more limited the scope of a name is, the shorter it should be. For example, a module name should indicate the use of the definitions and related procedures it contains, for example: Triangular_solver_mod, whereas a simple loop index variable may be called i or j.

Name user-written procedures using verbs.

Almost all procedures perform some task. Name them using one or more verbs that succinctly describe the operation carried out. If appropriate, follow each verb with a specific noun that describes the object being used. This method is especially useful when you name functions; it aids in distinguishing them from arrays. (See also Rules 7.2 and 16.)