(A Look Back at) Go To
Statement Considered Harmful
Edsger Dijkstra wrote a Letter to the Editor of Communications in 1968, criticizing the excessive use of
the go to statement in programming languages. Instead, he encouraged his fellow computer scientists to
consider structured programming. The letter, originally entitled “A Case Against the Goto Statement,”
was published in the March 1968 issue under the headline “Go To Statement Considered Harmful.” It
would become the most legendary CACM “Letter” of all time; “Considered Harmful” would develop
into an iconic catch-all. Dijkstra’s comments sparked an editorial debate that spanned these pages for over
20 years. In honor of the occasion, we republish here the original letter that started it all.
Editor:
For a number of years I have
been familiar with the observation that the quality of programmers is a decreasing function of
the density of go to statements
in the programs they produce.
More recently I discovered why
the use of the go to statement
has such disastrous effects, and I
became convinced that the go to
statement should be abolished
from all “higher level” programming languages (i.e. everything
except, perhaps, plain machine
code). At that time I did not
attach too much importance to
this discovery; I now submit my
considerations for publication
because in very recent discussions
in which the subject turned up, I
have been urged to do so.
PAUL WATSON
My first remark is that,
although the programmer’s activity
ends when he has constructed a
correct program, the process taking
place under control of his program
is the true subject matter of his
activity, for it is this process that
has to accomplish the desired
effect; it is this process that in its
dynamic behavior has to satisfy the
desired specifications. Yet, once the
program has been made, the “
making” of the corresponding process
is delegated to the machine.
My second remark is that our
intellectual powers are rather
geared to master static relations
and that our powers to visualize
processes evolving in time are relatively poorly developed. For that
reason we should do (as wise programmers aware of our limitations) our utmost to shorten the
conceptual gap between the static
program and the dynamic
process, to make the correspondence between the program
(spread out in text space) and the
process (spread out in time) as
trivial as possible.
Let us now consider how we
can characterize the progress of a
process. (You may think about
this question in a very concrete
manner: suppose that a process,
considered as a time succession of
actions, is stopped after an arbitrary action, what data do we
have to fix in order that we can
redo the process until the very
same point?) If the program text
is a pure concatenation of, say,
assignment statements (for the
purpose of this discussion
regarded as the descriptions of
single actions) it is sufficient to
point in the program text to a
point between two successive
action descriptions. (In the
absence of go to statements I can
permit myself the syntactic ambiguity in the last three words of
the previous sentence: if we parse
them as “successive (action
descriptions) “we mean successive
in text space; if we parse as “(
successive action) descriptions” we
mean successive in time.) Let us
