DISLIN is owned by the Max Planck Institute, for Solar System Research, Lindau, Germany.

Doxygen is an open-source program maintained by Dimitri van Heesch.

GNU, gcc, and gfortran are trademarks ofthe Free Software Foundation.

gnuplot is a plot program developed and maintained by the Free Software Foundation.

Intel Fortran is a trademark of Intel.

Interacter is a trademark of Interactive Services Ltd.

Java is a trademark of Oracle.

Linux is a trademark handled by the Linux Mark Institute.

Mac OSX is a trademark of Apple.

MATLAB is a trademark of The MathWorks, Inc.

McCabe IQ is a trademark ofMcCabe Software.

MS Visual Studio and MS Windows are trademarks of MicroSoft.

MySQL is an open source project at http://www.mysql.com.

Perl is a dynamic programming language. Its home page is http://www.perl.org.

PGI CUDA is a trademark of The Portland Group and NVIDIA.

PLplot is an open source project at http://plplot.sf.net.

PostScript and PDF are trademarks of Adobe.

Python is a dynamic programming language. Its home page is http://www.python.org.

ROBODoc is an open-source program maintained by Frank Slothouber.

SQLite is an open-source database management, residing at http://www.sqlite.org.

Tcl is a dynamic programming language developed and maintained by the Tcl Association. Tk is a user-interface library that can be used with Tcl and other languages. The home page for both is http://www.tcl.tk.

Xeffort is developed and maintained by Jugoslav Dujic.

The subject of this chapter is a simple framework for automating one particular aspect of testing: unit tests. Unit tests focus on “small” parts of a program, typically single subroutines or functions. The idea is these tests give confidence in the correct operation of routines. As the code for these tests should be considered part of the program, you can repeatedly run them during development and maintenance of the whole system. Some development methods take this to the extreme. Test-driven development (TDD), for instance, prescribes that the tests be written first, before you start implementing the actual code.

This is just one way to develop a program, but thinking about the ways you can test a particular routine helps to define its functionality. Most importantly, however, such unit tests become part of the program. Therefore, testing at that level is not an afterthought, implemented in ad hoc one-off programs.

Testing Frameworks

Junit is a well-known framework for unit tests in a Java programming environment [37]. It has been seminal for a whole range of similar frameworks for all manner, of programming languages. Junit depends on explicit support from several language features that Fortran does not have, such as special annotations and the possibility to programmatically get a list of routine (method) names from a library. Nevertheless, it is quite possible to implement a unit testing framework in Fortran as well.

There is extensive literature on reviewing code and design documents as a means to check that the software is performing as it should and that the implementation is maintainable and understandable. Some development methodologies, such as Extreme Programming [16], prescribe continuous reviews by peers [40]. In all forms, code reviews are about finding defects in the code, but they are not intended to criticize the programmer.

While the procedural (and psychological) aspects of code reviews are widely described, some practical aspects are not. For example, what should you be looking for in the code? It is not enough to check that the code adheres to the programming standard of the project it belongs to. Such a standard may not exist, be incomplete, or be focused on layout, not on questionable constructs that are a liability (see Appendix B).

What do you want to achieve with code reviews? First, you want to verify that the code is doing its job and that the code is of good enough quality:

1. ■ It is readable by others than the author.

2. ■ It is maintainable – adding new functionality or correcting bugs should not amount to hard labor.

3. ■ It is testable – do you understand what goes in and what comes out?

Secondly, the code should be portable. This means it should be possible to build the program and run it on a different operating system, and also with different compilers and versions of that same compiler. Many compilers offer options to check against the language standard.

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.)

Reading data and writing results are fundamental operations that are common to almost all programs. Fortran provides a built-in set of input/output (I/O) statements. These statements generally operate on data files residing on disk drives, and with devices, such as keyboards and console displays, which can be presented to a program by the operating system in a file-like manner. Different devices have different capabilities, so not all operations are supported on each one. The executable I/O statements, divided into two groups, are shown in Table 8.1.

Fortran has always structured its I/O capabilities around the read and write statements. These statements operate on Fortran “units,” which are represented by simple cardinal numbers called “unit numbers.” A unit that is connected to a data file typically occupies system resources, such as buffers and file descriptors, from the time it is connected, when the file is opened, until the time it is disconnected using the close statement.

General I/O Operations

Use the named constants in the intrinsic module iso_fortran_env.

The intrinsic module iso_fortran_env provides named constants to help make applications portable. These named constants include values for standard input, output, and error unit numbers, such as INPUT_UNIT, OUTPUT_UNIT, and various values returned by the iostat specifier, such as IOSTAT_END, an argument common to many of the I/O statements that return an integer indicating the success or the failure of the I/O operation (see Rules 104 and 105).