When to Use GO TO

As I have argued elsewhere, there are many good reasons to avoid GO TO. Nevertheless I wouldn't insist on an absolute prohibition. There are special circumstances when a GO TO may be acceptable, or even required.

Syntax constraints

Some languages, such as primitive dialects of FORTRAN and BASIC, do not support structured programming directly. They force you to use GO TOs to do almost anything.

In the case of COBOL, it may be difficult to avoid GO TO in input or output procedures for the SORT or MERGE verbs, or in declaratives.

Certain environments may impose GO TOs as well. For example: older versions of CICS inserted GO TOs into your code whether you wanted them or not. The best you could hope for was to contain the damage. Later versions of CICS (1.7 and up) have corrected this defect.

Performance constraints

When performance is critical, and GO TO can be demonstrated to provide better performance, you may be willing to accept the resulting obfuscation of your code.

Avoiding other problems

Avoiding GO TO may create other problems instead, such as deeply nested IF statements or a lot of flag-testing. In a typical case, the program branches to the end of a routine in order to recover from a series of potential error conditions.

This argument is more convincing for a language like C, where the scope of a goto is confined to a single function. In Cobol the damage is more widespread. It is difficult to imagine a case where GO TO offers a compelling advantage, even when the structured constructs are awkward to apply.

homeCOBOL Home [style forum]COBOL Style Forum