Key Takeaways — Chapter 6: Advanced Conditional Logic

Core Concepts

  1. 88-level condition names are the single most impactful readability tool in COBOL. They transform cryptic value comparisons (IF WS-STATUS = 'A') into self-documenting boolean expressions (IF ACCT-IS-ACTIVE). Define them for every status, type, and flag field without exception.

  2. EVALUATE is a decision table, not just a switch statement. The ALSO clause enables multi-dimensional decision logic that maps directly to business rules tables. EVALUATE TRUE allows arbitrary condition expressions in WHEN clauses, replacing deeply nested IF-ELSE chains.

  3. Always include WHEN OTHER. An EVALUATE without WHEN OTHER silently does nothing when no clause matches — one of the most dangerous failure modes in enterprise software.

  4. Limit IF nesting to three or four levels. Deeper nesting impairs readability and increases the probability of introducing bugs during maintenance. Use guard clauses, condition flags, or paragraph extraction to flatten nested structures.

  5. Use parentheses in all complex conditions. Even when operator precedence (NOT > AND > OR) would yield the correct result, parentheses communicate intent to the next programmer.

Patterns to Remember

  • Guard clause pattern: Check for invalid conditions first and exit early, leaving the "happy path" at the lowest nesting level
  • EVALUATE TRUE: Replaces nested IF-ELSE with a flat, readable list of conditions
  • EVALUATE subject ALSO subject: Implements two-dimensional (or multi-dimensional) decision tables
  • Group 88-levels: Define aggregate condition names (e.g., ACCT-IS-PROCESSABLE VALUE 'A' 'P') to simplify frequently checked groups of values
  • SET condition-name TO TRUE: Self-documenting alternative to MOVE that insulates logic from underlying value representation

Defensive Programming Checklist

  • [ ] Every EVALUATE has a WHEN OTHER clause
  • [ ] Every numeric field from external input is tested with IS NUMERIC before use in arithmetic
  • [ ] Every condition uses 88-level names rather than raw value comparisons
  • [ ] Complex conditions use explicit parentheses
  • [ ] IF nesting does not exceed 3-4 levels
  • [ ] END-IF and END-EVALUATE are used (never period-delimited conditionals in new code)

Common Pitfalls

Pitfall Risk Prevention
Missing WHEN OTHER Silent logic gaps Mandatory WHEN OTHER in all EVALUATEs
Deep nesting Maintenance errors Refactor at 3+ levels
Implied subject ambiguity Wrong condition evaluated Use explicit subjects and parentheses
NUMERIC test on wrong PIC type False passes/failures Know the PIC of the field being tested
No short-circuit guarantee Possible abend on division Nest IFs for dependent conditions
Dangling ELSE Wrong branch execution Always use END-IF