Tracing Execution Paths with GO TO

Tapan Desai has defended GO TO in an exchange of email, suggesting an argument I hadn't thought of before. I'm not sure that the following paraphrase is an accurate reflection of his views, but it's an interesting idea in any case.

When Tapan reads code, he likes to simulate the CPU, stepping through every line executed, without skipping any.

When you adopt this approach, you have to do a fair amount of bookkeeping to keep track of PERFORMs -- bookkeeping which you can largely avoid in code which uses GO TO instead.

When you encounter a PERFORM, you somehow have to remember where the PERFORM was, so that you can return to it when the PERFORMed paragraph ends. For example, you might leave one finger on page 17 of the listing, while you turn to page 24. After several levels of nested PERFORMs you start running out of fingers.

Even if you don't use your fingers -- you might simulate a stack with pencil and paper -- it's a nuisance to keep track of which PERFORMs are active. Even if you use an interactive debugger, it jumps around a lot.

By contrast: if you do everything with GO TOs, then you are wherever you are, and it doesn't matter where you were before. You only need one finger.

My Response

In large part, the point of modular coding is to make this kind of line-by-line treatment unnecessary. Most of the time you can just treat a PERFORM statement as a single operation and go on to the next statement. If you care about the internals of the PERFORMed paragraph you can always look at it, but you don't have to.

By contrast: when you encounter a GO TO, you have no choice. You have to follow it wherever it leads, picking your way through all the lower-level details.

(In practice I almost never do this kind of step-by-step reading, except on somebody else's unstructured code. On the rare occasions when I do, it is indeed a pain in the neck, with or without GO TOs.)

Consider an analogy. The WRITE verb hides a great many details about record blocking and buffer management. When you read or code a WRITE, you can treat it as a single atomic operation, without worrying about those details. In the same way, a PERFORM isolates the details of lower levels so that they don't clutter up the higher levels.

Ideally, and most of the time in practice, you can read or write a good modular paragraph without knowing or caring about the code which PERFORMs it. Each paragraph should be written at its own level of abstraction. As a result, you don't have to keep too many things in your mind at one time. Another result is that you seldom need more than one finger.

[home]Cobol Home [style forum]Cobol Style Forum