Skip to main content

Essay: Go To Statement Considered Harmful

Context and Thesis
Published in 1968 amid growing concern over the complexity and unreliability of software, Dijkstra’s letter argues that the goto statement should be abolished from higher-level programming languages. He contends that arbitrary jumps in control flow are a chief source of program confusion, making it harder to understand, verify, and maintain code. The central claim is not about programmer morality but about cognitive limits: humans struggle to reason about intricate, time-evolving states, so programming styles and language constructs must reduce mental load rather than increase it.

Cognitive Limits and Control Flow
Dijkstra observes that programs are written as linear texts but executed as dynamic processes. When control moves largely forward through a structured arrangement of blocks, each with single entry and single exit, the reader can keep a coherent mental model and reason locally. The goto statement breaks this alignment by enabling jumps into and out of blocks arbitrarily. Such jumps create tangled “spaghetti code,” forcing readers to track the program counter across distant locations. This undermines modular understanding and makes errors difficult to detect.

Proof, Invariants, and Termination
A major theme is that programs should be designed to facilitate correctness proofs. With structured constructs, one can attach invariants to program blocks and loops, arguing that if the invariant holds before a block, it will hold after. Termination can be shown via a well-founded measure that decreases at each iteration. Goto disrupts this discipline: multiple entry and exit points spoil clean invariants, and uncontrolled jumps obscure the conditions under which termination arguments apply. By favoring constructs that restrict control transfer, programmers retain the ability to reason about partial correctness and termination in a compositional way.

Structured Alternatives
The letter champions a small set of control structures, sequencing, conditional selection, and iteration, as sufficient for most tasks. Conditional constructs (if-then-else) make alternatives explicit; loops (while or repeat-until) make repetition explicit and bound it to a single test. These forms preserve single-entry, single-exit properties and support nesting, which builds programs as hierarchies of well-defined blocks. Dijkstra demonstrates that patterns often handled with goto, such as early loop exits or multi-stage procedures, can be expressed with structured loops, boolean flags, and carefully arranged conditionals, maintaining clarity without sacrificing expressiveness.

Readability, Reliability, and Economy
Dijkstra rejects the notion that goto is justified for reasons of efficiency or convenience. While a goto can sometimes shorten code textually, it lengthens the mental path a reader must traverse. The true economy lies in clarity and verifiability, not in shaving a few instructions. He anticipates that compilers will optimize structured control effectively, erasing any performance advantage of ad hoc jumps. More importantly, he prioritizes reliability: structured programs localize reasoning and defects, reducing the debugging burden and making maintenance feasible as systems grow.

Discipline and Design
Beyond a language prescription, the letter promotes a programming discipline: design programs so that their structure mirrors the structure of the argument for correctness. Each block should correspond to a proven step; each loop should have an invariant; each conditional should make alternatives explicit. Goto undermines this alignment by introducing unanticipated paths. By removing it, languages and programmers are nudged toward designs that fit human reasoning.

Legacy
The letter catalyzed structured programming, shifting norms toward block-structured languages and away from unrestricted jumps. It framed programming as an intellectual activity constrained by human cognition and supported by formal reasoning. Although limited, carefully constrained jumps persisted in some contexts, the mainstream moved toward constructs that preserve clean control flow. The enduring message is that language features should serve human understanding first, because clarity is the foundation of correctness.
Go To Statement Considered Harmful

A widely cited open letter arguing that unrestricted use of the GO TO statement harms program clarity and correctness, catalyzing the structured programming movement and debate on programming style.