Chapter 21: COBOL Coding Standards and Best Practices -- Key Takeaways

Chapter Summary

Coding standards transform COBOL from a language that merely runs correctly into one that can be read, maintained, and enhanced by teams of programmers over decades. This chapter presented a comprehensive set of coding standards and best practices covering naming conventions, paragraph organization, structured programming principles, documentation standards, and code review practices that are followed in well-run mainframe development shops.

Naming conventions are the most visible element of any coding standard. We examined how consistent, descriptive naming of data items, paragraphs, sections, files, and programs makes code self-documenting and dramatically reduces the time needed to understand unfamiliar programs. Effective COBOL naming uses hierarchical prefixes that indicate scope and purpose (such as WS- for WORKING-STORAGE, LS- for LINKAGE SECTION, and FD- or file-specific prefixes for file records), combined with descriptive suffixes that convey business meaning.

Paragraph organization and PERFORM structure are equally important. Structured programming in COBOL relies on a top-down hierarchy of paragraphs connected through PERFORM statements, where each paragraph has a single entry point, a single exit point, and a clear, well-defined purpose. We discussed the conventions for paragraph numbering, the maximum recommended paragraph length, and the importance of keeping each paragraph focused on a single task. The chapter also covered documentation standards, including the use of identification comments, paragraph-level comments, and inline comments, as well as the structure and content of code review checklists that help teams enforce standards consistently.

Key Concepts

Naming conventions should use hierarchical prefixes to indicate data scope: WS- for WORKING-STORAGE, LS- for LINKAGE SECTION, FD-prefixed names for file-level items, and application-specific prefixes for group-related items.
Data item names should be descriptive and convey business meaning: WS-CUSTOMER-BALANCE is preferable to WS-BAL or WS-X, and the name should make the item's purpose clear without requiring a comment.
Paragraph names should follow a numbering scheme (such as 1000-MAIN-PROCESS, 2000-READ-INPUT, 2100-VALIDATE-RECORD) that reflects the program's hierarchical structure and call order.
Each paragraph should have a single, well-defined purpose, a single entry point, and a single exit point; paragraphs longer than 50 lines are candidates for decomposition.
Structured programming in COBOL means using only PERFORM, IF/EVALUATE, and PERFORM UNTIL as control structures, and avoiding GO TO except in limited, sanctioned patterns such as GO TO in an error-exit paragraph.
The PERFORM THRU pattern, where used, should be limited to the convention of PERFORM paragraph-name THRU paragraph-name-EXIT, with the EXIT paragraph containing only the EXIT statement.
Top-down design means the main controlling paragraph calls high-level paragraphs, which in turn call more detailed paragraphs, creating a readable hierarchy that mirrors the program's logical flow.
Consistent indentation enhances readability: Area A (columns 8-11) for division headers, section headers, paragraph names, 01/77 levels, and FD entries; Area B (columns 12-72) for all other statements.
Data items should be grouped logically within WORKING-STORAGE, with related items organized under meaningful group (01-level) headers and separated by blank comment lines.
Documentation standards should require an identification block at the top of each program (program name, author, date, purpose, modification history), paragraph-level comments explaining each paragraph's purpose, and inline comments for non-obvious logic.
Code review checklists should verify naming compliance, structured programming adherence, proper initialization of variables, correct file status checking, and adequate error handling.
Shop standards are the site-specific coding rules adopted by an organization; they may extend or restrict the language standard to suit the organization's tools, processes, and maintenance requirements.
Copybook usage standards should specify when to create a new copybook versus when to use an existing one, naming rules for copybook members, and the governance process for modifying shared copybooks.
Maintainability is the overriding goal of all coding standards: code that is easy to read, easy to modify, and easy to debug serves the organization far longer than clever or compact code.

Common Pitfalls

Inconsistent naming within a program: Mixing prefixes (sometimes WS-, sometimes W-, sometimes no prefix) within the same program defeats the purpose of naming conventions and confuses maintainers.
Paragraph names that describe implementation, not purpose: A paragraph named 3000-MOVE-FIELDS tells the reader what statements are in it, not why they are there. A name like 3000-FORMAT-OUTPUT-RECORD conveys the business purpose.
Monolithic paragraphs: A single paragraph that spans hundreds of lines and performs multiple unrelated tasks is nearly impossible to debug, test, or modify safely. Break it into focused, single-purpose paragraphs.
Excessive use of GO TO: While GO TO has a few sanctioned uses (such as a forward branch to an exit paragraph), general use of GO TO creates spaghetti code that is extraordinarily difficult to follow and maintain.
Undocumented modification history: When changes are made to a program without updating the modification history in the IDENTIFICATION DIVISION or a standard comment block, future maintainers cannot determine when, why, or by whom changes were made.
Over-commenting obvious code: Comments like "Move customer name to output" on a MOVE CUST-NAME TO OUT-CUST-NAME add visual noise without information. Comment the why, not the what.
Ignoring shop standards in favor of personal style: Individual preferences must yield to team-wide consistency. A program that follows its author's personal conventions but not the shop standard creates maintenance burden for everyone else.

Quick Reference

      *================================================================*
      * PROGRAM-ID. CUST1000
      * AUTHOR.     J. SMITH
      * DATE.       2025-01-15
      * PURPOSE.    PROCESS DAILY CUSTOMER TRANSACTIONS
      * MODIFIED.   2025-03-01 J. DOE  - ADDED PREMIUM LOGIC
      *             2025-06-10 A. LEE  - FIXED BALANCE CALC
      *================================================================*

      * Naming convention examples
       01  WS-CUSTOMER-RECORD.
           05  WS-CUST-ID            PIC X(10).
           05  WS-CUST-NAME          PIC X(30).
           05  WS-CUST-BALANCE       PIC S9(7)V99 COMP-3.
           05  WS-CUST-STATUS        PIC X(01).
               88  CUST-ACTIVE       VALUE "A".
               88  CUST-CLOSED       VALUE "C".

      * Paragraph organization pattern
       PROCEDURE DIVISION.
       0000-MAIN-CONTROL.
           PERFORM 1000-INITIALIZE
           PERFORM 2000-PROCESS-FILE
               UNTIL WS-EOF-FLAG = "Y"
           PERFORM 9000-FINALIZE
           STOP RUN.

       1000-INITIALIZE.
      *    Open files and initialize counters
           ...

       2000-PROCESS-FILE.
           PERFORM 2100-READ-INPUT
           IF WS-EOF-FLAG NOT = "Y"
               PERFORM 2200-VALIDATE-RECORD
               PERFORM 2300-UPDATE-MASTER
           END-IF.

       9000-FINALIZE.
      *    Close files and display summary
           ...

What's Next

Chapter 22 transitions to enterprise data access by introducing embedded SQL and DB2 fundamentals. You will learn how to embed SQL statements within COBOL programs using the EXEC SQL and END-EXEC delimiters, declare host variables to exchange data between COBOL and DB2, and process query results through cursors. The coding standards and naming conventions established in this chapter apply directly to DB2 programming, where clear naming of host variables, consistent cursor management patterns, and thorough SQLCODE checking are essential for writing reliable database programs.