In free format programs spaces, or blanks, in statements can be thought of as being significant. Consecutive spaces / blanks have the same meaning as one blank. Blanks are not allowed in language keywords. For instance, INT EGER is not the same as INTEGER. Neither are blanks allowed in names defined by the programmer. The name hours could not be written as ho urs; not that any one would be likely to do so. If a name is made up from two words it is common practice to use an underscore as a separator. The continuation character & acts as a space and so cannot be used in the middle of names and keywords.
Keywords and names may not be run together without spaces or some other ``punctuation" to separate them. Thus,
SUBROUTINEClear
would be illegal and not equivalent to
SUBROUTINE Clear
Likewise,
INTEGER :: a
is valid and
INT EGER :: a
is not.
Blanks must appear:
INTEGER FUNCTION fit(i) ! is valid
INTEGERFUNCTION fit(i) ! is not
INTEGER FUNCTIONfit(i) ! is not
Blanks are optional between certain pairs of keywords such as: END < construct >, where < construct > is DO, FUNCTION, PROGRAM, MODULE, SUBROUTINE and so on. Blanks are mandatory is other situations. Adding a blank between two valid English words is generally a good idea and will be valid.
Apart from observing the above rules, spaces can be used liberally to increase the readability of programs. Thus the following statements,
POLYN=X**3-X**2+3*X-2.0
and
POLYN = X**3 - X**2 + 3*X - 2.0
are equivalent.
To sum up, the rules governing the use of blanks are largely common sense. Judicious use of blanks and sensible use of upper and lower case can often significantly clarify more complicated constructs or statements, and some systematic convention for this use can make it very much easier to read and hence to write correct programs. As statements can start anywhere on a line most programmers use indentation to highlight control structure nesting for example within IF blocks and DO loops.
Return to corresponding overview page 