Go To Statement Considered Harmful

Control structure is a reasoning aid

Dijkstra’s letter argues about the relationship between static program text and the changing process it describes. The archive uses the manuscript title A Case against the GO TO Statement and explains the published title. The argument is not that deleting one keyword proves correctness. It concerns whether progress can be described through manageable coordinates supplied by structured control, including procedure context and loop iterations.

Consider a program finding the first negative element of a finite list. Define the result to be its zero-based index, or the list length when no negative element exists. The original teaching pseudocode is simple:

Pseudocode:
i = 0
while i < length(values) and values[i] >= 0:
    i = i + 1
return i

The condition uses left-to-right short-circuit evaluation. At the loop header, 0<=i<=n and every earlier element is nonnegative. That statement explains the meaning of i at one stable textual point. Each iteration advances the processed prefix by one. On exit, either i=n or the element at i is negative. In either case the returned value meets the contract.

Compare coordinates with arbitrary paths

Now imagine several labels that jump into the middle of the condition and increment sequence. At one label, i might refer to the next unexamined element; at another, it might refer to the element just found negative; at a third, it might already have been incremented. The same variable value needs additional path history to interpret it. A reviewer must recover that hidden history before checking array bounds or first-occurrence behavior.

An execution counter uniquely identifies a moment in one deterministic run, but it rarely supplies a useful invariant across all runs. “After step 137” does not say which prefix has been checked when inputs differ. A structured loop header expresses a relation between program position, data, and progress that generalizes across inputs.

Mechanical transformations can preserve confusion

Any tangled flow can be represented by a dispatcher loop with a state variable and a large switch. That removes explicit goto syntax, but the state transitions may preserve exactly the same reasoning burden. The useful refactoring discovers coherent operations and invariants, not merely a different spelling of jumps.

For the search example, extracting a predicate that reports whether an element is negative can clarify intent if it is pure and total on valid inputs. If the predicate mutates i or changes the list, the previous invariant may fail. Local control structure does not excuse hidden effects or an unstable input collection.

Apply the argument without turning it into a slogan

Exceptions, callbacks, asynchronous tasks, and early exits also create nonlocal control relationships. Some are essential and can be used clearly. The question is which state and obligations remain understandable at each boundary. A finally block that releases a resource may improve reasoning even though control can arrive there from several failures.

Tests should cover empty input, a negative first element, a negative last element, and no negative element. These cases expose likely mistakes, but the invariant explains all valid finite inputs. The proof also requires a decreasing remaining-length measure for termination and an assumption that length and contents do not change during the scan.

The practical standard is therefore assessable: identify meaningful program points, state what variables mean there, and show how each path preserves the relevant facts. Structured syntax helps achieve that standard, while abstraction, effect discipline, and explicit contracts complete the reasoning.

again: if x == y goto done
       if x > y goto reduce_x
       y = y - x
       goto again
reduce_x: x = x - y
          goto again
done: return x

def gcd_subtract(x,y):
    assert x > 0 and y > 0
    while x != y:
        if x > y:
            x -= y
        else:
            y -= x
    return x
assert gcd_subtract(21,15) == 3

def matrix_sum(a, columns):
    assert all(len(row) == columns for row in a)
    total = 0
    for i in range(len(a)):
        for j in range(columns):
            total += a[i][j]
    return total
assert matrix_sum([[2,5,1],[4,0,3]],3) == 15
assert matrix_sum([[],[]],0) == 0

• Go To Statement Considered Harmful: University of Texas at Austin