Text:

Comprehensive Structured COBOL, third edition,
by L. Wayne Horn and Gary M. Gleason, Course Techonology

Programming standards for this course:

• Required in all Source Programs:
  
  1. The PROGRAM-ID name will be EX- and the program exercise number (such as: EX-5-1).
  2. Include an AUTHOR paragraph in the IDENTIFICATION DIVISION with your name as the only entry.
• Data-names (in general):
  Select data-names that are meaningful in context. For instance, ACCOUNT-BALANCE would be better documentation than BAL for the balance in a customer account record. Always work within the COBOL rules for programmer-selected names.
• Punctuation:
  Use the comma and semicolon sparingly (if at all). They are not necessary in a source program, but can be used for readability.
• Indention:
  Indent Area B entries whenever a line is subordinate to the preceding line. For instance, indent all statements between a PERFORM and the corresponding END-PERFORM. Common COBOL practice is to use a four-space indent. Because COBOL-85 has far more extensive provisions for block structures, you may wish to use a two-space indention in the PROCEDURE DIVISION. (Many examples in the text use two spaces for indention.)
• Paragraph Modules:
  Break program tasks into separate modules, each with a specified single task. Select paragraph names that describe the function of the module. Numbering the paragraphs (which is allowed for paragraph names in the PROCEDURE DIVISION) may help to organize modules according to their purpose and sequence of execution:

  Sample Paragraph Name	Type of Module
  000-MAIN	Main Control Module
  100-INITIALIZE	First level initialize actions
  120-READ	Second level actions
  200-DETAIL-LOOP	First level loop actions
  300-TERMINATE	First level final procedures

• Field Size and the PICTURE clause:
  Fields of up to four characters in length may be defined using consecutive PICTURE characters (like XXX or XXXX). For all fields whose lengths exceed four characters, use parentheses for the field length (like X(5) rather than XXXXX). This makes it easier to add up individual values to check the record length.
• Record description level numbering:
  When defining a record in the DATA DIVISION, use a level number of 01 for the record (required by COBOL). Use level numbers higher than 01 for first- and second-level fields. Some programmers prefer to use multiples like 05, 10, 15, and so on. However, 02, 03, etc. will also work.
• Source Program Comments:
  To provide a uniform apearance to source programs, use the following line spacing standards:
  1. Precede each division header and section header with at least one comment line using asterisks or hyphens.
  2. Precede 01 record descriptions in the WORKING-STORAGE SECTION with a comment line explaining the record's usage in this problem.
  3. In the PROCEDURE DIVISION, separate lines of code with comments when it improves or clarifies the documentation.
• File and Record names:
  A file and its associated record will have the same name, suffixed by -FILE and -RECORD, respectively. The only exception to this will be the PRINTER file, in which case the record name can have the suffix -LINE instead of -RECORD.
• Field names:
  Field names within a record will be prefixed by a two- or three-letter abbreviation indicating the record of which it is a member. For example:

                      FD  STUDENT-MASTER-FILE.
                      01  STUDENT-MASTER-RECORD.
                          02  SM-STUDENT-SSN          PIC X(9).
                          02  SM-STUDENT NAME         PIC X(30).
                          02  SM-GPA                  PIC 9V99.
          

• Other data-names:
  For fields defined in the WORKING-STORAGE SECTION other than those defined as part of an input or output record, use the prefix WS- (like WS-RECORD-COUNT or WS-EOF-FLAG).
• Edited Pictures:
  Repeat necessary edited picture characters rather than use parentheses. For example, use ZZZ,ZZZ.99 rather than Z(3),Z(3).9(2) even though COBOL allows it. Using the first version is similar to the way the output will appear and is less confusing. Use the same format on your printer spacing chart.
• Arithmetic:
  
  1. Use the COMPUTE statement whenever the sequence of calculations is defined by any but the simplest formula. Use it also when the arithmetic operations are mixed and intermediate results are not needed.
  2. Use the GIVING form of arithmetic statements if
     1. you do not want to change the value of any operand invloved in the operation, or
     2. the destination field is numeric-edited.
  3. The many forms of the DIVIDE statement can be confusing. In choosing between INTO and BY formats, select the one that best documents the application itself. If you need to retain the remainder, then use either format 4 or format 5 with the REMAINDER option.
• Report Output:
  Plan your reports using a printer spacing chart. Define heading lines in the WORKING-STORAGE SECTION using constant values in FILLER fields, one per coding line. Use the WRITE with the FROM option to output lines other than the record defined under the FD entry for the output file. Use the AFTER ADVANCING option of the WRITE verb for variable line control. Create your own numeric data item to contain the number of lines to advance. In setting up page control, decide what you need for the top and bottom margins, then compute the number of lines in the body. For each WRITE, add the line spacing for that WRITE to your line counter.
• Interactive Screen I/O:
  Keep formatting information in the DATA DIVISION by using ACCEPT and DISPLAY with SCREEN SECTION screen records (except for occasional brief messages). Use some convention for organizing screen records in the SCREEN SECTION. Two possibilities are:
  1. prefix each screen record name with a number for ordering,
  2. arrange them in alphabetic sequence based on screen name.
  Plan your screen layout using a layout form. Use relative line and column positioning. This simplifies moving the entire screen layout.
• Conditional Operations:
  Always terminate an IF with an END-IF rather than using a period. Periods should only be used to terminate a paragraph name and after the last statement of a paragraph.
  When forming compound relational conditions invloving both AND and OR logical operators, always use parentheses to indicate the order in which evaluations are to be made. Do this even if the natural hierarchy does not require them. This makes the condition more readable and easily understood.
  To improve readablility, write condition expressions in a form that is consistent with the English description of the application. When used this way, the CONTINUE statement can be helpful.
  Use indention rules with the EVALUATE verb. Each condition should be indented either two or four spaces. Corresponding actions under the conditions should be indented an additional two or four spaces.
  When using condition names, make certain that each condition name adequately describes the condition. Documentation value is lost if you must refer back to its definition in the DATA DIVISION whenever you see it in the PROCEDURE DIVISION.
  When writing nested IF statements, always use indention to indicate each level of IF. If you have several levels, you may wish to indent two spaces rather than four. Check each IF to see that it has a corresponding END-IF.
  Exercise caution when using implied subjects or operators. Be careful of an English description that may be misleading because it is similar to the proper COBOL form.