Adopt and use a consistent set of rules for case

DO ITER = 1 , MAXITERS

3.2 Case

7. Adopt and use a consistent set of rules for case.

It is essential when discussing case in Fortran to emphasize that it is a case-insensitive language. The following variations all represent the same variable:

VORTICITY, ^vorticity, ^Vorticity, ^VortiCity. Compilers that, as an optional feature, permit distinguishing entities based solely on case are not standard;

you should not use this option.

Strictly speaking, prior to Fortran 90, standard-conforming code had to be written in uppercase letters. The Fortran character set described in the older standards specified only the 26 uppercase letters.

Beginning with Fortran 90, lowercase letters have been formally permitted, and all known compiler vendors supported them. However, because so much old code is still in use, it is still common to encounter code that conforms to the original restriction. Here is a snippet of code from the LINPACK Users’

Guide (see Reference [20]):

20 M = MOD (N , 4 )

I F (M . EQ . 0 ) GO TO 40 DO 30 I = 1 , M

DY( I ) = DY( I ) + DA * DX( I ) 30 CONTINUE

I F (N . LT . 4 ) RETURN 40 MP1 = M + 1

Nowadays, programmers can use lowercase letters, and the underscore is part of the character set. The maximum number of characters that can be used to form a name has grown from the original number of 6, to 31 in Fortran 90/95, to 63 in Fortran 2003. It is now common to see a variable such as molecular weight.

Even though the language is case-insensitive, you will often see that programs, especially large ones, are written with specific case conventions. Using different combinations of case, such as using all one case for certain types of program entities and the opposite case for others, capitalizing certain types of entities, or using a consistent set of combinations of uppercase letters and underscores,

helps differentiate between the different types of entities. On the other hand, modern text editors have greatly obviated this; they automatically recognize different types of entities, and the programmer can configure the editor to highlight them by using different fonts and colors, both foreground and background, and by using underlining. Furthermore, the careful naming of all entities, as described in Chapter 4, decreases the need to use different case rules for different program entities.

A wide range of opinion exists on this subject. A survey of professional lit-erature reveals the use of many different conventions. Rather than strictly prescribing a particular set of case rules, we suggest here, in several subrules, some alternatives. They are only a few of the many possibilities. The important point is that whatever rule you choose, you should use it consistently.

7.1 Use lowercase throughout.

As implied earlier, writing all entities using solely lowercase characters is being widely adopted. Words spelled with all lowercase letters tend to be more legible than those spelled using only uppercase ones. Furthermore, there is little chance of confusing the letter “i” with the numeral “1,” the letter “B”

with the numeral “8,” etc., which can be a problem with some fonts.

Because case is not used to distinguish between types of program entities, the importance of using a clear naming scheme, as described in Chapter 4, grows.

It also encourages the use of underscores in names, which some programmers prefer not to use. If underscores are used, the editor should not be configured to underline entities that contain them; the underscore would then be difficult to see. Most, but not all, of the entities in this book are written using lowercase letters.

7.2 Capitalize the names of all user-written procedures.

Capitalizing the first character of the names of all subroutines and functions makes them stand out in the code. For the most part, this isn’t a problem with subroutines because they are normally preceded by the keyword ^call. Their names can, however, be passed as arguments to procedures. With functions, capitalizing the names is more useful; it helps distinguish them from array references in expressions. So, in the following two lines of code, the first is a reference to a function, the second to an element of an array:

a name = Employee name ( i ) i t e m s = i t e m l i s t ( i , j )

You may prefer to not use underscores. If this is the case, consider writing the function name using what is commonly called UpperCamelCase, where each word has the first letter capitalized, like this:

a name = EmployeeName ( i )

Capitalizing procedure names has the additional advantage of helping to dis-tinguish between derived-type components that are data objects and those that are functions referenced using the notation new to Fortran 2003.

Here are two snippets of code: in the first, the assignment statement is to an element of componentprotein codes of derived type cell t, identifiable by the lowercase component name protein codes; the second is a function reference, identifiable by the capitalized function name, to the type-bound functionNext whose first argument is a data object of type cell t (see Section 11.3):

t y p e c e l l t

i n t e g e r , a l l o c a t a b l e : : p r o t e i n c o d e s ( : ) t y p e ( c e l l t ) , p o i n t e r : : n e i g h b o r => n u l l ( ) c o n t a i n s

p r o c e d u r e : : Next => N e x t n e i g h b o r end t y p e c e l l t

t y p e ( c e l l t ) : : t h i s , n e x t c e l l i n t e g e r : : p r o t e i n

! component r e f e r e n c e

p r o t e i n = t h i s%n e i g h b o r%p r o t e i n c o d e s ( i p ) . . .

! f u n c t i o n r e f e r e n c e

n e x t c e l l = t h i s%n e i g h b o r%Next ( )

You can use two other schemes to emphasize that a name is a function: one is to name the function using a verb. So, a better name for the function Employee namewould beGet employee name. The second, as in the example, is to separate the name of the function from the opening parentheses by a space and to not do so when referencing an array. In this book, we capitalize all procedure names. We also separate the name of the procedure from the opening parentheses with at least one space. (See also Rules 26 and 16.)

7.3 Write all named constants using uppercase letters.

Named constants (entities declared using^parameter) stand out in your code if you write them using all uppercase characters. The use of all uppercase differ-entiates them from, say, variables read in from a file. All uppercase characters are used in the code in this book when writing named constants:

i n t e g e r , parameter : : MAX ELEMENTS = 200 . . .

r e a d ( u n i t =10 , fmt =*) m a x e l e m e n t s

7.4 Begin the name of all data entities using a lowercase letter.

To set off data entities from the other entities discussed so far, begin them with a lowercase letter. If you are using underscores, the entire name can be

lowercase like this: loop voltage, or, if underscores are not used, write the name using lowerCamelCase like this:loopVoltage. In this book, we employ all lowercase characters when writing data entities, separating words using underscores.

3.3 Indentation