Control Flow

Structured programming and the control flow theorem

Before structured programming (1960s), programs used arbitrary GOTO jumps — control could leap to any line at any time. Dijkstra's 1968 paper argued that well-structured programs should use only three control flow patterns: sequence (execute in order), selection (if/else, switch), and iteration (loops). Böhm and Jacopini proved these three are sufficient for any computable function. Modern languages reflect this: GOTO is gone from Python, Java, and Rust entirely, and discouraged in C and Go.

Short-circuit and guard clauses

A common pattern in structured programming is the guard clause: check for error conditions at the top of a function and return early if they're present, rather than nesting all the main logic inside an if block. This produces flatter, more readable code.

# Deep nesting — hard to read
def process(user, data):
    if user is not None:
        if user.is_active:
            if data is not None:
                return data.process()

# Guard clauses — flat and readable
def process(user, data):
    if user is None: return None
    if not user.is_active: return None
    if data is None: return None
    return data.process()

Pattern matching (Python 3.10+, Rust, Swift)

Modern match statements in Python, Rust, and Swift go beyond simple value comparison — they support structural pattern matching: destructuring tuples, matching object types and their attributes, binding values from matched structures. Rust's match is exhaustive — the compiler requires every possible variant to be handled, preventing missed cases.

enum Shape {
    Circle(f64),          // radius
    Rectangle(f64, f64),  // width, height
}

fn area(shape: Shape) -> f64 {
    match shape {
        Shape::Circle(r) => std::f64::consts::PI * r * r,
        Shape::Rectangle(w, h) => w * h,
        // Compiler error if any variant is missing — exhaustive
    }
}

Formal semantics of if/else

In formal operational semantics, the if statement has two reduction rules:
if true then S₁ else S₂ → S₁
if false then S₁ else S₂ → S₂
The condition expression is evaluated first; the result selects which branch reduces. This formalises the intuition that exactly one branch executes.

Control flow in compiled code

At the machine code level, an if/else compiles to a conditional branch instruction — JE (jump if equal), JNZ (jump if not zero), etc. on x86. The condition sets flags in the status register; the branch instruction reads those flags to decide whether to jump. Modern CPUs use branch prediction to speculatively execute the likely branch before the condition is resolved. Mispredictions (the speculated branch was wrong) cause a pipeline flush — a ~15–20 cycle penalty. This is why replacing an unpredictable branch with branchless arithmetic (e.g. using bitwise operations) can improve performance in inner loops.