A case against the GOTO

  • Authors:
  • W. A. Wulf

  • Affiliations:
  • -

  • Venue:
  • Classics in software engineering
  • Year:
  • 1979

Quantified Score

Hi-index 0.00

Visualization

Abstract

This is one of two companion papers presented at the 25th ACM National Conference in October 1972, a time when the debate about goto statements was reaching its peak. Indeed, so intense was the argument that the issue was considered to be almost separate and distinct from the concept of Structured programming. Wulf's viewpoint, reflected in the title of the paper, is that goto statements are dangerous, and should be avoided. Wulf admits that not all gotos are bad; as he says, " . . . this argument addresses the use of the goto rather than the goto itself." There are legitimate uses of the goto, but they are rare and can be eliminated altogether with proper high-level language constructs. One of Wulf's main themes is borrowed from Dijkstra, namely, that program correctness is becoming more and more important, and that it cannot be achieved by conventional testing. If proofs of correctness (either formal or informal) are the way of the future, then --- as Wulf illustrates with a small programming example --- it is essential that the code be written in a well-structured fashion. Regrettably, this still is an issue that most real-world programmers ignore: They argue that their programs are so complex that they can't develop correctness proofs regardless of whether their code is structured or unstructured; so they usually opt for the easiest coding approach, which (in languages like COBOL) may not be wellstructured at all. Wulf also demonstrates in this paper a mechanism for converting unstructured code into equivalent structured code. The method is taken directly from Bt:ihm and Jacopini, but is considerably easier to understand when Wulf explains it. Finally, Wulf addresses the practical possibility of eliminating the goto statement; he considers the two most common practical objections to be convenience and efficiency. Whether or not structured programming is convenient, he argues, is largely a function of the programming language. With suitable constructs to express the various forms of loops and decisions, together with some escape constructs to exit prematurely from the middle of a block structure, the goto is hardly ever missed. Here Wulf speaks from experience that few could claim in 1972: He and his colleagues already had been programming for three years in a systems implementation language called BLISS, a language that has no goto statement! Wulf's comment regarding efficiency has become a classic: "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason -- including blind stupidity." He recognizes that there are applications or, more commonly, portions of applications in which efficiency is a valid issue, but maintains that the problem of efficiency is best left to optimizing compilers, a point with which most people agree today. wulrs final, and perhaps most effective, argument against the goto and in favor of well-structured code follows: In the long run, optimizing compilers will be able to generate considerably better object code for structured programs than for rat's-nest programs. The 1972 ACM Conference at which Wulf presented his paper was considerably more accessible than, say, the 1971 IFIP Conference in Yugoslavia. Certainly, a reasonable number of practicing industry-oriented programmers attended, and Wulf's paper must have had some impact on them, but his message reached only a very small percentage of the potential audience. Indeed, there are many programming shops today in which Wulf's paper is just as relevant as it was in 1972, shops in which debates about the goto statement still are being waged.