Donald Knuth, Structured Programming

Structured Programming with go to StatementsDONALD E. KNUTH

Stanford University, Stanford, California 9~S05

A consideration of several different examples sheds new light on the problem of ereat-ing reliable, well-structured programs that behave efficiently. This study focuseslargely on two issues: (a) improved syntax for iterations and error exits, making itpossible to write a larger class of programs clearly and efficiently without

go to

state-ments; (b) a methodology of program design, beginning with readable and correct,but possibly inefficient programs that are systematically transformed if necessary intoefficient and correct, but possibly less readable code. The discussion brings out op-posing points of view about whether or not

go to

statements should be abolished;some merit is found on both sides of this question. Fina!ly, an attempt is made todefine the true nature of structured programming, and to recommend fruitful direc-tions for further study.

Keywords and phrases:

structured programming,

go to

statements, language design,event indicators, recursion, Boolean variables, iteration, optimization of programs,program transformations, program manipulation systems searching, Quieksort,efficiency

CR categories:

4.0, 4.10, 4.20, 5.20, 5.5, 6.1 (5.23, 5.24, 5.25, 5.27)You may go when you will go,And I will stay behind.

--Edna St. Vincent Millay

[66]Most likely you go your way and I'll go mine.

--Song title by Bob Dylan

[33]Do you suffer from painful elimination?

--Advertisement, J. B. Williams Co.

INTRODUCTION

A revolution is taking place in the way wewrite programs and teach programming, be-cause we are beginning to understand theassociated mental processes more deeply. Itis impossible to read the recent book

Struc-tured programming

[17; 55] without having itThis research was supported in part by the Na-tional Science Foundation under grant numberGJ 36473X, and by IBM Corporation.change your life. The reasons for this revolu-tion and its future prospects have been aptlydescribed by E. W. Dijkstra in his 1972 Tur-ing Award Lecture, "The Humble Program-mer" [27l.As we experience this revolution, each ofus naturally is developing strong feelings oneway or the other, as we agree or disagreewith the revolutionary leaders. I must admitto being a nomhumble programmer, egotisti-Copyright (~) 1974, Association for Computing Machinery, Inc. General permission to republish,

but

not for profit, all or part of this material is granted, provided that ACM's copyright notice isgiven and that reference is made to this publication, to its date of issue, and to the fact that reprint-ing privileges were granted by permission of the Association for Computing Machinery.

Computing Surveys, V?L 6, No. 4, Dee,ember 1974

262 ,

Donald E. Knuth

CONTENTS

INTRODUCTION1. ELIMINATION OF

so to

STATEMENTSHistorical BackgroundA Searching ExampleEfficiency

Error

ExitsSubscript CheckingHash CodingText ScanningA ConfessionTree SearchingSystematic Elimination

Event

IndicatorsComparison of FeaturesSimple Iterations2. INTRODUCTION OF

so to

STATEMENTSRecursion EliminationProgram Manipulation SystemsReeursion vs. IterationBoolean Variable EliminationCoroutinesQuicksort : A DigressionAxiomatics of JumpsReduction of Complication3. CONCLUSIONSStructured ProgrammingWith

go to

StatementsEfficiency

The

FutureACKNOWLEDGMENTSAPPENDIXBIBLIOGRAPHY

eal enough to believe that my own opinionsof the current treads are not a waste of thereader's time. Therefore I want to express inthis article several iof the things that struckme most forcefully as I have been thinkingabout structured programming during thelast year; several of my blind spots were re-moved as I ivas learning these things, and Ihope I can convey some of my excitement tothe reader. Hardly any of the ideas I willdiscuss are my own; they are nearly all thework of others, but perhaps I may be pre-senting them in a new light. I write thisarticle in the first person to emphasize thefact that what I'm saying is just one man'sopinion; I don't expect to persuade everyonethat my present views are correct.Before beginning a more technical discus-sion. I should confess that the title of thisarticle was chosen primarily to generateattention. There are doubtless some readerswho are convinced that abolition of go

to

statements is merely a fad. and they may seethis title and think, "Aha! Knuth is rehabili-tating the go to statement, and we can goback to our old ways of programmingagain." Another class of readers will see theheretical title and think, "When are die-hards like Knuth going to get with it?" Ihope that both classes of people will read onand discover that what I am really doing isstriving for a reasonably well balanced view-point about the proper role of go to state-ments. I argue for the elimination of go to'sin certain cases, and for their introduction inothers.I believe that by presenting such a view Iam not in fact disagreeing sharply withDijkstra's ideas, since he recently wrote thefollowing: "Please don't fall into the trap ofbelieving that I am terribly dogmaticalabout [the go to statement]. I have theuncomfortable feeling that others are makinga religion out of it, as if the conceptualproblems of programming could be solved bya single trick, by a simple form of codingdiscipline!" [29]. In other words, it, seemsthat fanatical advocates of the New Pro-gramming are going overboard in their strictenforcement of morality and purity inprograms. Sooner or later people are goingto find that their beautifully-structured

Computing

Surveys, Vol. 6, No. 4, December 1974

Structured Programming with

go to Sta~ment~

!

programs are running at only half the speed--or worse--of the dirty old programs theyused to write, and they will mistakenly blamethe structure instead of recognizing what isprobably the real culprit--the system over-head caused by typical compiler implementa-tion of Boolean variables and procedure calls.Then we'll have an unfortunate counter-revolution, something like the current rejec-tion of the "New Mathematics" in reactionto its over-zealous reforms.It may be helpful to consider a furtheranalogy with mathematics. In 1904, Bert-rand Russell published his famous paradoxabout the set of all sets which aren't mem-bers of themselves. This antinomy shook thefoundations of classical mathematical rea-soning, since it apparently brought verysimple and ordinary deductive methods intoquestion. The ensuing crisis led to the riseof "intuitionist logic", a school of thoughtchampioned especially by the Dutch mathe-matician, L. E. J. Brouwer; intuitionismabandoned all deductions that were based onquestionable nonconstructive ideas. For awhile it appeared that intuitionist logicwould cause a revolution in mathematics.But the new approach angered David Hil-bert, who was perhaps the leading mathema-tician of the time; Hilbert said that "For-bidding a mathematician to make use of theprinciple of the excluded middle is likeforbidding an astronomer his telescope or aboxer the use of his fists." He characterizedthe intuitionist approach as seeking

"to

save mathematics by throwing overboardall that is troublesome ... They would chopup and mangle the science. If we wouldfollow such a reform as they suggest, wecould run the risk of losing a great part of ourmost valuable treasures" [80, pp. 98-99,148-150, 154-157, 184-185, 268-270].Something a little like this is happeningin computer science. In the late 1960's wewitnessed a "software crisis", which manypeople thought was paradoxical becauseprogramming was supposed to be so easy.As a result of the crisis, people are now be-ginning to renounce every feature of pro-gramming that can be considered guilty byvirtue of its association with difficulties. Notonly go to statements are being questioned;

* 263

we also hear complaints about floating-pointcalculations, global variables, semaphores,pointer variables, and even assignmentstatements. Soon we might be restricted toonly a dozen or so programs that are suffi-ciently simple to be allowable; then we willbe almost certain that these programscannot lead us into any trouble, but ofcourse we won't be able to solve manyproblems.In the mathematical ease, we know whathappened: The intuitionists taught the othermathematicians a great

deal about

deductivemethods, while the other mathematicianscleaned up the classical methods and even-tually "won" the battle. And a revolutiondid, in fact, take place. In the computerscience case, I imagine that a similar thingwill eventually happen: purists will point theway to clean constructions, and others willfind ways to purify their use of floating-pointarithmetic, pointer variables, assignments,etc., so that these classical tools can be usedwith comparative safety.Of course all analogies break down, includ-ing this one, especially since I'm not yetconceited enough to compare myself toDavid Hilbert. But I think it's an amusingcoincidence that the present programmingrevolution is being led by another Dutchman(although he doesn't have extremist viewscorresponding to Brouwer's); and I doconsider assignment statements and pointervariables to be among computer science's"most valuable treasures!'.At the present time I think we are on theverge of discovering at last what program-ming languages should really be like. I lookforward to seeing many responsible experi-ments with language design during the nextfew years; and my dream is that by 1984 wewill see a consensus developing for a reallygood programming language (or, more likely,a coherent family of languages). Further-more, I'm guessing that people will becomeso disenchanted with the languages they arenow using--even COBOL and FORTrAN--that this new language, UTOPXA84, will havea chance to take over. At present we are farfrom that goal, yet there are indicationsthat such a language is very slowly takingshape.

Computing Surveys, Vol. 6, No. 4,

December 1974