Indentation and White Space

• Put no more than one statement on a line. Resist the temptation to save a little space by coding something like:

          MOVE KERMIT TO FROG MOVE MISS TO PIGGY
  

  Anyone using his eyeballs to scan the code for a MOVE will only look at the beginning of each line. He'll miss the second one.
• Use indentation consistently to reflect logical structure.

  With a PERFORM UNTIL, indent the UNTIL clause on the next line (though for an in-line PERFORM, the PERFORM and the UNTIL may go best on the same line).

  Indent the AT END clause of a READ statement.

  Indent the WHEN clauses within an EVALUATE, and further indent whatever is subordinate to each WHEN.

  Indent whatever follows an IF or ELSE clause. Each ELSE should line up with the corresponding IF.

  Nested IFs are a judgement call. Usually there should be a level of indentation for each level of nesting. Sometimes, however, we code an ELSE-IF series to implement a case structure, where the various branches are mutually exclusive. In that case it makes sense to line up the ELSE-IFs at the same level of indentation, even though they are nested as far as the compiler is concerned.

• Adopt a uniform number of spaces for indentation. Either three or four spaces is about right. I prefer three -- it shows up well to the eye but gives you a little more elbow room for deep nesting or long variable names.
• Don't code SKIP1, SKIP2, or SKIP3. They're ugly. They clutter the screen. Just code a blank line where needed, with or without an asterisk in column 7.
• For the same reasons, don't code EJECT for a form feed. Instead, put '/' in column 7.
• Use blank lines to break up your code into more readable chunks. In particular, use them to isolate IF statements (when not nested) and PERFORM UNTIL statements, since these constructs are critical for understanding the flow of control.

  Sometimes it is useful to use blank lines to isolate a group of related statements, such as a series of MOVEs which collectively populate a record.

• Line up your PICTURE clauses, TO clauses, and similar fragments, on nearby lines.

  Demonstration: which of the following is easier to read?

        MOVE 'TRE' TO SIG-POMER-X.
        MOVE WS-MESH-RIBIT TO SIG-POMER-Y.
        MOVE TEMP-CLOMMER-FOOM TO SIG-BELUCHI-FOOM.
        MOVE INPUT-RUPISH-NORP TO SIG-NORP PREV-NORP.  
        MOVE TAB-FLABBER-STIN (ERP-SUB) TO SIG-ERP-STIN.  
        MOVE STALGER-BIM-FLAG TO SIG-POLTER-SW.
  

  ...or:

        MOVE 'TRE'                        TO SIG-POMER-X.
        MOVE WS-MESH-RIBIT                TO SIG-POMER-Y.
        MOVE TEMP-CLOMMER-FOOM            TO SIG-BELUCHI-FOOM.
        MOVE INPUT-RUPISH-NORP            TO SIG-NORP
                                             PREV-NORP.  
        MOVE TAB-FLABBER-STIN (ERP-SUB)   TO SIG-ERP-STIN.
        MOVE STALGER-BIM-FLAG             TO SIG-POLTER-SW.
  

  Dave Sailer suggests:

  I like to align (or break up with blank lines) move statements into logical groups. For example, if I'm building an output file from two input files the "TO" statements might align differently for the two input files:

     MOVE I-FILE1-FIELD1     TO  O-FILE2-FIELD1
     MOVE I-FILE1-FIELD2     TO  O-FILE2-FIELD2
   
     MOVE I-FILE2-FIELD1           TO  O-FILE2-FIELD3
     MOVE I-FILE2-FIELD1           TO  O-FILE2-FIELD4
  

  While it pays to be fussy about alignment, you can also overdo it. Some authorities seriously advise you, for example, to start all your PICTURE clauses in column 38, and your TO clauses in column 43. That's silly. Line them up wherever they look reasonable, as long as they are neat and readable.

COBOL Home

COBOL Style Forum