Structured Programming and Dijkstra’s Campaign Against Uncontrolled Jumps
Structured programming reframed program clarity as an engineering property, arguing that control flow should be composed from understandable structures rather than arbitrary jumps.
Control flow became a software engineering problem
Early high-level languages often made unrestricted jumps a normal way to organize execution. GOTO statements were flexible, but large programs could accumulate tangled paths that were difficult to understand from the source text alone.
Edsger W. Dijkstra argued that the problem was not aesthetic. A programmer needed a manageable correspondence between the static program and the dynamic process it created.[1]
Dijkstra’s 1968 letter became famous under a title he did not choose
Dijkstra submitted a text titled “A Case against the GO TO Statement.” Communications of the ACM editor Niklaus Wirth retitled the published letter “Go To Statement Considered Harmful.” Dijkstra later recalled the episode and noted how the new title became far more famous than he expected.[2]
The phrase became shorthand for a larger argument about making program behavior easier to reason about.
The target was unrestricted control transfer
Dijkstra was not arguing that every low-level jump instruction could literally disappear from machine code. His concern was whether high-level programming should expose arbitrary jumps as a routine structuring mechanism.[1]
Program text should help locate execution state
Structured control constructs make it easier to infer how execution reached a point in the program. Arbitrary jumps weaken that relationship between source structure and runtime history.
Sequence, selection and iteration became the canonical building blocks
Structured programming encouraged programs composed from nested blocks, conditionals and loops with clearer entry and exit behavior. This made control flow more local and reduced the number of paths a reader had to reconstruct mentally.
The movement connected practical style with deeper results showing that structured constructs were expressive enough for general computation.
The goal was reasoning, not merely formatting
Dijkstra’s broader work treated programming as a discipline in which correctness should be argued systematically. Structured control flow was valuable because it made local reasoning and proof obligations more tractable.[3]
This explains why structured programming became closely associated with stepwise refinement, invariants and formal reasoning.
Local structure supports local proof
If a block has clear preconditions, postconditions and limited exits, a programmer can reason about it without reconstructing arbitrary paths through distant statements.
Readability became a correctness aid
Readable structure is not only for future maintainers. It helps the original programmer detect mistaken assumptions before they become faults.
Structured programming became a broader design movement
The 1972 volume Structured Programming by Ole-Johan Dahl, Dijkstra and C.A.R. Hoare helped consolidate the approach into a wider software-design philosophy.[4]
Languages and teaching materials increasingly favored block structure and explicit loops over flowcharts dominated by jumps.
The debate changed programming language design
Later languages still often included escape mechanisms such as break, continue, exceptions or labeled control flow, but they generally made structured constructs the default way to express ordinary execution.
The argument had shifted from whether programmers could jump anywhere to which higher-level control forms best communicated intent.
The slogan also became oversimplified
Dijkstra later complained that many people cited the famous title without reading the underlying reasoning.[2] Some retellings reduce structured programming to a ban on one keyword, missing its connection to comprehensibility and proof.
The historical lesson is broader: syntax rules matter because they shape the mental models programmers must maintain.
Why structured programming remains foundational
Modern languages differ dramatically from the procedural languages of the 1960s, but most still encourage control structures whose behavior is locally understandable. Functions, exceptions, async constructs and pattern matching have extended the vocabulary, yet the engineering goal remains familiar.
Computer History Museum’s software-engineering collection places structured programming among the major methodological shifts of the 1970s.[5] Dijkstra’s lasting contribution was to insist that program structure should serve human reasoning, not merely machine execution.
Works Cited
- 01
- 02
- 03E.W. Dijkstra Archive — Notes on Structured Programming cs.utexas.edu
- 04
- 05Computer History Museum Software Preservation Group — Books on Software Engineering softwarepreservation.computerhistory.org
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead