Structured programming with go to statements

• Authors: D. Knuth
• Venue: Classics in software engineering
• Year: 1979

For serious students of structured programming, and also for language designers, Knuth's "Structured Programming with go to Statements" is probably the paper to read. It is by far the most complete description of structured programming of all the selections in this book. Even though it originally was published in late 1974, Knuth's ideas have not aged a bit. The title, as Knuth acknowledges, is somewhat of a misnomer: " . . . I should confess that the title of this article was chosen primarily to generate attention." Indeed, he is not arguing that structured programming always should be carried out with goto statements; instead, as he says, "what I am really doing is striving for a reasonably well-balanced viewpoint about the proper role of go to statements." Like a number of other authors whose views are presented in this book, Knuth seems deeply concerned that the average programmer will over-react to the "no goto" philosophy. Reflecting that concern, the first few pages of Knuth's paper give an indication of the fanaticism of its time --- a fanaticism that has largely died away. For history buffs, Knuth has carefully documented the origins of structured programming. He claims that the programming style now referred to as "structured programming" actually was first practiced by D.V. Schorre in 1960, and that was followed by publication of the work of Peter Naur in 1963 and of George Forsythe in 1964 -- all of this before the better-known works of Dijkstra, and of Böm and Jacopini. There are three major themes in Knuth's paper, and avast number of examples to illustrate each one, One theme --- a familiar one, if you've read many of the other papers in this book is that a program needs to be rewritten several times before it can beconsidered a truly good program. As Knuth says, " . . . I learned again that I should always keep looking for improvements, even When I have a satisfactory program." Indeed, one gets the impression that Knuth views this as the major virtue of structured programming: The requirement to eliminate gotos forces the programmer to rewrite and thus think more about what he was trying to accomplish with his program. A second theme --- one that you won't find in any of the other papers - is that efficiency is important in some programming applications, and that the programmer needs the freedom to use gotos to optimize critical portions of a program. Actually, Martin Hopkins makes the same point in "A Case for the GOTO" [Paper 9], but he does so much less forcefully than Knuth. Knuth recognizes the danger of overemphasizing optimization; as he says, "premature optimization is the root of all evil." And, he does state that only three percent of the code in a typical program ever needs to be optimized; but for that critical three percent, he demonstrates that structured code often is twenty to thirty percent less efficient than equivalent code with gotos. Unfortunately, the point is repeated so many times, with so many examples, that the average reader is likely to conclude that Knuth is obsessed with efficiency. However, given the number of authors exhorting programmers to ignore efficiency altogether, it is probably very healthy to have someone argue for a careful consideration of program efficiency. Knuth's third main theme is that structured programming could be made much more practical with the addition of a few language constructs. In addition to constructs like LEAVE and BREAK, Knuth argues for a "situation" construct patterned after a proposal originally made by C.T. Zahn. In keeping with the heretical title of his paper, Knuth introduces a fourth theme: There are times when the programmer should put gotos into his code, rather than take them out. For example, gotos can be used to convert recursion to iteration; or to implement coroutines; or to eliminate Boolean variables by branching into common code. In this context, Knuth suggests the following strategy: First, write the program in a structured manner to convince yourself that it is correct; then, transform it into an efficient program, possibly by introducing some goto statements; and, finally, leave the original structured code behind as documentation, so that subsequent readers can understand how the transformation took place. Whether the average programmer would go through these steps in an orderly, formal way is something worth pondering. My own suspicion is that it won't work, but I'm often branded a skeptic. To conclude: It's probably best not to read Knuth's paper in one sitting, for you almost surely will become mentally fatigued by the eight major examples, each of which is rewritten three or four (or more!) times in an ALGOL-like pseudocode. Read the paper piece by piece, and do read the code --- you'll learn a lot from it!