Against GO TO in COBOL

Against GO TO

GO TO in other languages

The following summary is mostly based on the discussion by Steve McConnell in Code Complete:

Programs heavily larded with GO TOs are almost always heavily larded with bugs. That statement is true in practice even if it need not be true in theory. Whenever I have looked closely at a program with many GO TOs, I have always found bugs, which had often been obscured by the tangled logic.

GO TOs tend to make a program hard to read and hard to understand. They can turn the code into spaghetti.
GO TOs make it more difficult to prove the correctness of a program, whether by a formal proof or by the human brain.

GO TO is never needed in any language that supports a few basic constructs of structured programming. Bohm and Jacopini demonstrated this principle on theoretical grounds in the 60's.

With GO TOs, your indentation cannot reflect the logical structure of your program.

GO TOs make it difficult for compilers to optimize code.

These points apply to COBOL as well as other languages. In COBOL, GO TO creates more problems, as outlined below.

GO TO in COBOL

McConnell didn't write about COBOL. He wrote mostly about languages like C, where a goto has limited scope. A goto in C can branch only to a destination within the same function where the goto resides. Even if that one function is a tangled mess, the tangle does not extend beyond the bounds of the function.

In COBOL, a GO TO is not bounded in this way. You can GO TO any paragraph within the same section, or to any section in the program. If you don't use sections, you can GO TO any paragraph in the same program. Once you GO TO, you're stuck with fall-through logic until you hit an EXIT, GOBACK, or similar construct.

These possibilities undermine modularity. You can't tell what happens at the end of a paragraph unless you know how you entered the top. When used excessively, GO TOs can make a program so convoluted that you can't understand any of it without understanding all of it.

Reading a Program with GO TOs

When I study an unfamiliar program, I first scan for all the GO TOs. If there aren't any, I heave a sigh of relief. Otherwise I have to examine every single one of them to determine:

How control enters the paragraph -- PERFORM, PERFORM THRU, a previous GO TO, or a fall-through from the previous paragraph.

Where control passes, and where it stops.

This analysis is tedious, time-consuming, and error-prone, especially if there are multiple possible paths before or after the GO TO. Until I complete this analysis, however, I can't safely change any of the logic, because I won't know the impact of any change I make.

Some of these difficulties arise not from GO TO but from PERFORM THRU and the associated fall-through logic. In the absence of GO TO, however, it is trivial (though tedious) to eliminate all fall-through logic.

Disciplined GO TO's

Care and discipline in the use of GO TO can reduce these problems. In effect, one can use GO TO to implement the standard constructs of structured programming. As a result, the scope of each GO TO is both limited and easily identified.

While such discipline may reduce the analysis required to understand a program, it does not eliminate it. You still have to identify the scope of every GO TO and every PERFORM THRU.

Without GO TO or PERFORM THRU, the analysis is greatly streamlined. You can readily identify the contexts in which a paragraph is PERFORMed. You can add paragraphs, break them into pieces, or move them around, without fear that you will unexpectedly disrupt some stream of fall-through logic.

COBOL Home

COBOL Style Forum