|
Fortran 90 programming tips
by Walt Brainerd
|
- Don't be lazy. Include the keyword program and the name of the program in every program-end statement.
- As a matter of good programming practice, every variable that is used in a Fortran program should be listed in a type declaration.
|
- Every program and procedure should include the implicit none statement to turn off implicit typing. Note: This rule may be broken for very short programs.
|
- It is good programming practice to echo all input data. However, it will be impractical to follow this rule when there is a large amount of input data.
|
- Whenever possible, use the default input format. This makes preparation of data easier and less prone to error.
|
- It is good programming practice to declare quantities to be parameters whenever possible. Assigning a constant value to a parameter rather than a variable tells the reader that the value corresponding to that name will never change when the program is running. This also makes it possible for the compiler to produce a diagnostic message if the programmer inadvertently tries to change its value.
|
- Since parameters are named constants, use of a parameter name instead of the corresponding constant makes a program more readable. It is easy to forget what role an unnamed constant plays in a program.
|
- Perhaps the most important reason for using a parameter declaration is that the program can be modified easily if the value represented by the parameter name needs to be changed. The programmer can then be sure that the constant will be correct whenever it is used throughout the program.
|
- Blank characters and blank lines should be used freely in Fortran programs. This improves readability.
|
- In a context that requires conversion from complex to integer or real, or from real to integer, use the intrinsic type conversion functions, even if they are not required.
|
- It is good programming practice to use the default read format whenever possible. Explicit input format specifications demand strict adherence to specified positions for each value in the input data. The slightest misalignment of the input data usually results in incorrect values being assigned to the variables. By comparison, the default input format is more tolerant of variations in alignment, and is easier to use.
|
- The statements in each block of a construct should be indented some consistent number of spaces past the statements which delimit the block.
|
- It is good programming practice to warn the user when a situation occurs that the program is not designed to handle.
|
- Don't sacrifice clarity of the program to shorten execution time by a few microseconds. Not only is the program harder to get right and maintain, but with a good optimizing compiler, the improvement in execution time may be smaller than expected, or even nonexistent.
|
- Don't use a real do variable. Roundoff error will cause systematic drift of successive values, and it will be impossible to guarantee that the do block will be executed with the do variable equal to the stopping value.
|
- Self-contained subtasks should be written as procedures.
|
- Use a "result" variable in every function procedure. It is easier to remember to use the "result" variable universally than it is to treat the "result" variable as a special case.
|
- Don't change the values of dummy arguments in function procedures.
|
- Always indicate the intent attribute for procedure arguments.
|
- Use an asterisk in the length declaration for a dummy argument of type character, and use the built-in function len to obtain its true length when needed.
|
- Blanks should be placed before and after the percent sign in structure component references. This is not required, but it improves readability.
|
- If you use a Fortran name followed by the suffix _type to name a derived type, the base name (without the suffix) is may be used for variables and structure components of that type. For example, the component name may be type name_type.
|
|
|
