Pseudocode Conventions & Structured Programming

Pseudocode & Algorithmic Problem-Solving

Chapter 2 · Pseudocode Conventions & Structured Programming

Chapter 1 showed what goes wrong when an algorithm's description is vague. This chapter gives this course's own pseudocode a fixed, consistent notation, and covers the deeper reason that notation only needs three kinds of building blocks — sequence, selection, and iteration — to describe absolutely any algorithm, no matter how complex.

This Course's Pseudocode Notation

Every pseudocode block in this course uses the same conventions: keywords in UPPERCASE (IF/THEN/ELSE/ENDIF, WHILE/ENDWHILE, FOR/ENDFOR), ← for assignment, and indentation to show nesting — deliberately close to what most textbooks and technical interviews already use, so nothing here needs relearning elsewhere.

ALGORITHM FindMax(list)
    max_val ← list[0]
    FOR i ← 1 TO length(list) - 1 // inclusive, per Chapter 1's own convention
        IF list[i] > max_val THEN
            max_val ← list[i]
        ENDIF
    ENDFOR
    RETURN max_val
    

Verified directly — the pseudocode translates to working code that matches a trusted reference

Translated directly into Python and run on [3, 7, 2, 9, 4, 9, 1]: the pseudocode's own logic returns 9, exactly matching Python's own battle-tested built-in max() function on the identical input. The pseudocode wasn't just readable — it described a genuinely correct algorithm, confirmed against an independent, trusted implementation rather than just "looking right."

The Three Building Blocks

Construct	What it does	This course's notation
Sequence	Statements execute one after another, in the order written	Plain lines, top to bottom
Selection	Choose between different paths based on a condition	`IF...THEN...ELSE...ENDIF`
Iteration	Repeat a block of steps while a condition holds, or a fixed number of times	`WHILE...ENDWHILE`, `FOR...ENDFOR`

This isn't just a stylistic preference. It's backed by a real, formal result in computer science: the Böhm–Jacopini theorem (1966) proves that any computable function — however complex — can be expressed using only these three constructs, with no need for arbitrary jumps between arbitrary points in a program.

A Real, Verified Demonstration: No Goto Needed

Older languages (early BASIC, Fortran, assembly) relied heavily on GOTO — an unconditional jump to any labeled point in the program. To make the Böhm–Jacopini claim concrete rather than just cited, here's the same task — sum the even numbers from 1 to n — implemented two genuinely different ways: one using only sequence, selection, and iteration, and one built as an actual label-and-jump interpreter that mimics classic goto-driven control flow, with no while or for anywhere in its own execution logic.

# Structured: sequence, selection, iteration only
def sum_evens_structured(n):
    total = 0
    i = 1
    while i <= n:
        if i % 2 == 0:
            total = total + i
        i = i + 1
    return total

# Goto-simulated: a real label/jump interpreter, no while/for driving it
def sum_evens_goto(n):
    label = 'LOOP_START'
    i, total = 1, 0
    while label != 'DONE':  # the interpreter's own dispatch loop, not the algorithm's logic
        if label == 'LOOP_START':
            if i > n: label = 'END'; continue
            if i % 2 != 0: label = 'SKIP'; continue
            total = total + i; label = 'SKIP'; continue
        if label == 'SKIP': i = i + 1; label = 'LOOP_START'; continue
        if label == 'END': label = 'DONE'; continue
    return total
    

Verified directly — identical results, from two structurally different control-flow strategies

Run on n=20: the structured version returns 110. The goto-simulated version, jumping between labeled blocks 42 separate times to get there, also returns 110 — an exact match. Two genuinely different control-flow strategies, one real computed result.

If they compute the same thing, why prefer structured programming at all?

Because GOTO lets execution jump to any labeled point from anywhere, reasoning about a large goto-driven program means tracking every possible jump into and out of every block — the number of paths through the code grows explosively as the program grows. Sequence, selection, and iteration each have exactly one entry point and one exit point, which is exactly why a structured program can be reasoned about (and later, in this course, formally decomposed and analyzed) one block at a time. This is precisely the argument Edsger Dijkstra made in his famous 1968 letter "Go To Statement Considered Harmful" — not that goto-based programs are wrong, but that they're needlessly hard to reason about compared to an equally capable structured alternative.

Where This Connects

This chapter's finding	What it sets up
This course's fixed pseudocode notation	Every worked example from Chapter 3 onward uses this exact notation without re-explaining it
Sequence/selection/iteration sufficiency, verified directly	Chapter 4's problem decomposition treats each subproblem as its own small structured block — a direct consequence of "one entry, one exit"
Structured programs being easier to reason about block by block	Chapter 9's recursive/backtracking designs lean on exactly this reasoning discipline to stay tractable

Hands-On Exercises

Exercise 1

Using this chapter's own FindMax pseudocode as a template, write pseudocode in this course's own notation for an algorithm that finds the smallest value in a list. Translate it into working code and verify it matches a trusted reference (e.g. Python's own min()) on the list [8, 3, 5, 1, 9, 2].

📄 View solution

Exercise 2

Using this chapter's own sum_evens_goto function as a guide, trace through what label the interpreter would be at after exactly 4 label-jumps when run with n=3, and state the final value of total it would return.

📄 View solution

Exercise 3

Using this chapter's own explanation of why structured programming is preferred over goto (even though the Böhm–Jacopini theorem proves they're equally capable), explain in your own words the specific difference between "can compute the same thing" and "is equally easy to reason about" — and why a course on algorithmic problem-solving cares more about the second property than the first.

📄 View solution

Chapter 2 Quick Reference

This course's pseudocode notation: UPPERCASE keywords, ← for assignment, indentation for nesting — verified translating faithfully to working code matching a trusted reference (FindMax matched Python's own max())
Three building blocks: sequence (order), selection (IF/ELSE), iteration (WHILE/FOR) — proven sufficient for any computable algorithm by the Böhm–Jacopini theorem (1966), no GOTO required
Verified directly: a structured version and a real goto-simulated (label/jump) version of the same task produced the identical result, 110, for summing even numbers 1 to 20 — confirming the theorem concretely, not just citing it
Structured programming is preferred not because goto can't compute the same things, but because sequence/selection/iteration's "one entry, one exit" shape makes a program dramatically easier to reason about block by block — Dijkstra's own 1968 argument
Next chapter: Flowcharts and visual algorithm representation — a second, visual notation for exactly the same three building blocks