Structured programming and subroutines

A subroutine is a named 'out of line' block of code that may be executed (called) by simply writing its name in a program statement.

That is AQA's own wording, and the phrase 'out of line' is worth keeping: the code is written once, somewhere separate from the main program, and then run from wherever you need it by naming it.

SUBROUTINE greetUser()
    OUTPUT 'Welcome to the system'
    OUTPUT '-------------------'
ENDSUBROUTINE

# The main program — 'calling' the subroutine
greetUser()
… other statements …
greetUser()

Writing greetUser() calls it: execution jumps to the subroutine, runs its statements, then returns to the line after the call and carries on.

Procedures and functions

The specification's heading is "Structured programming and subroutines (procedures and functions)". The difference is simple:

	Procedure	Function
Purpose	Carries out a task	Carries out a task and returns a value
Returns a value?	No	Yes
How it is used	As a statement on its own	Its result is used — assigned or output
Example	displayMenu()	total ← calculateVAT(price)

# A PROCEDURE — does something, returns nothing
SUBROUTINE displayMenu()
    OUTPUT '1 - Add'
    OUTPUT '2 - Quit'
ENDSUBROUTINE

displayMenu()

# A FUNCTION — returns a value that must be used
SUBROUTINE calculateArea(length, width)
    RETURN length * width
ENDSUBROUTINE

area ← calculateArea(5, 3)      # area now holds 15

The test: does it hand a value back? If yes, it is a function and its result must be used — assigned to a variable or output. Calling calculateArea(5, 3) on its own line throws the answer away.

AQA tip. In a definition question, include the phrase 'out of line' and the idea that it is called by writing its name. Both appear in the specification's own wording and are what mark schemes credit.

Parameters are used to pass data into a subroutine, so the same code can work on different values each time it is called.

SUBROUTINE greet(name)
    OUTPUT 'Hello, ', name
ENDSUBROUTINE

greet('Amina')      # Hello, Amina
greet('Ben')        # Hello, Ben

Without a parameter the subroutine could only ever greet one fixed person. The parameter is what makes it general.

More than one parameter — an explicit requirement

The specification states students "should be able to use subroutines that require more than one parameter."

SUBROUTINE calculateTotal(price, quantity, taxRate)
    subtotal ← price * quantity
    RETURN subtotal * (1 + taxRate)
ENDSUBROUTINE

cost ← calculateTotal(12.50, 3, 0.20)

Order matters. The values are matched to the parameters in the order they are written: 12.50 → price, 3 → quantity, 0.20 → taxRate. Swapping them silently produces a wrong answer — calculateTotal(3, 12.50, 0.20) would still run, but would calculate the wrong total.

The AQA terminology note — worth knowing

"Teachers should be aware that the terms arguments and parameters are sometimes used but in examinable material we will use the term parameter to refer to both of these."

Some textbooks distinguish the parameter (the name in the definition) from the argument (the actual value passed). AQA does not test this distinction — use the word parameter for both and you are safe.

How data flows in

                 the value 5 is passed IN
                          ↓
SUBROUTINE double(number)
    RETURN number * 2
ENDSUBROUTINE

result ← double(5)        # result = 10

Inside the subroutine, number behaves like a local variable holding the value that was passed in.

AQA tip. In a "describe the use of parameters" question, say what they do (pass data into a subroutine) and why (so the same subroutine can be reused with different values). The reusability point is where the second mark usually is.

A return value passes data out of a subroutine, back to the routine that called it.

SUBROUTINE calculateArea(length, width)
    area ← length * width
    RETURN area
ENDSUBROUTINE

roomArea ← calculateArea(5, 3)      # roomArea = 15
OUTPUT 'The area is ', roomArea

Three things to know

1. RETURN ends the subroutine immediately. Any statements after it are never executed.

SUBROUTINE test(x)
    RETURN x * 2
    OUTPUT 'This never runs'      # unreachable
ENDSUBROUTINE

2. The returned value must be used. Calling a function without doing anything with its result throws the answer away:

calculateArea(5, 3)              # the 15 is calculated then discarded
area ← calculateArea(5, 3)       # correct — the value is kept
OUTPUT calculateArea(5, 3)       # also correct — the value is used

3. A subroutine can return early from inside a selection, which is genuinely useful:

SUBROUTINE isValidMark(mark)
    IF mark < 0 OR mark > 100 THEN
        RETURN False
    ENDIF
    RETURN True
ENDSUBROUTINE

IF isValidMark(75) THEN
    OUTPUT 'Valid'
ENDIF

AQA tip. A question may ask you to "describe how data is passed out of a subroutine". The answer is: using a return value, which is sent back to the calling routine and can then be stored in a variable or used directly.

The specification is precise here. Subroutines may declare their own variables, called local variables, and local variables usually:

• only exist while the subroutine is executing
• are only accessible within the subroutine

SUBROUTINE calculateAverage(a, b, c)
    total ← a + b + c        # 'total' is a LOCAL variable
    RETURN total / 3
ENDSUBROUTINE

result ← calculateAverage(4, 8, 6)
OUTPUT total                          # ERROR — 'total' does not exist here

When the subroutine finishes, total is destroyed. The main program cannot see it.

Why local variables are good practice — the explain marks

Reason	Explanation
No name clashes	Two subroutines can each have a variable called total without interfering, because each exists separately
No unintended side effects	A subroutine cannot accidentally change a variable the rest of the program relies on
Easier to debug	If a value is wrong, only the subroutine that owns it could be responsible — the search area is tiny
Memory is freed	The variable is destroyed when the subroutine ends, so memory is not held unnecessarily
Genuinely self-contained	The subroutine can be reused in another program without dragging dependencies with it

The name-clash point, shown properly

SUBROUTINE addScores(a, b)
    total ← a + b            # local to addScores
    RETURN total
ENDSUBROUTINE

SUBROUTINE countItems(list)
    total ← 0                # a DIFFERENT, separate 'total'
    FOR i ← 0 TO LEN(list) - 1
        total ← total + 1
    ENDFOR
    RETURN total
ENDSUBROUTINE

Both use the name total, and neither affects the other. Without local variables, the second subroutine would overwrite the first's value — a bug that would be extremely hard to trace in a large program.

Global variables — the contrast

A global variable is declared outside any subroutine and is accessible everywhere. It is occasionally convenient but generally poor practice, because any part of the program can change it, so tracking down a wrong value means searching the entire program rather than one subroutine.

AQA tip. For "explain why local variables are good practice", give two developed reasons rather than a list. The strongest pair is name clashes and no unintended side effects, each with a consequence attached.

The specification defines it precisely: "the structured approach including modularised programming, clear well-documented interfaces (local variables, parameters) and return values."

The three components

1. Modularised programming. The problem is decomposed (3.1.1) into sub-problems, and each becomes its own subroutine. Instead of one long program, you have several small named blocks that each do one identifiable job.

2. Clear, well-documented interfaces. The interface of a subroutine is how the rest of the program communicates with it: which parameters it takes and what it returns. A clear interface means you can use a subroutine knowing only what it does, not how it works.

# A well-documented interface
# calculateVAT(price, rate)
#   price : Real  — the pre-tax amount
#   rate  : Real  — the VAT rate, e.g. 0.20
#   returns: Real — the VAT amount to add
SUBROUTINE calculateVAT(price, rate)
    RETURN price * rate
ENDSUBROUTINE

3. Return values. Data comes out through return values rather than through shared global variables, so each module is self-contained.

Advantages of the structured approach — the explain marks

Advantage	Why
Easier to write	Each small sub-problem is simpler to solve than the whole problem at once
Easier to test and debug	Each subroutine can be tested independently, and a fault is isolated to one module
Reusable	A working subroutine can be called many times, and reused in other programs
Shorter code	Code written once and called repeatedly, rather than duplicated
Easier to read and maintain	Meaningful subroutine names make the main program self-documenting
Team working	Different programmers can write different modules simultaneously, because the interfaces are agreed

Before and after

# WITHOUT structure — one long block, duplicated logic
OUTPUT 'Enter mark 1'
m1 ← STRING_TO_INT(USERINPUT)
WHILE m1 < 0 OR m1 > 100
    OUTPUT 'Invalid'
    m1 ← STRING_TO_INT(USERINPUT)
ENDWHILE
OUTPUT 'Enter mark 2'
m2 ← STRING_TO_INT(USERINPUT)
WHILE m2 < 0 OR m2 > 100          # the same logic AGAIN
    OUTPUT 'Invalid'
    m2 ← STRING_TO_INT(USERINPUT)
ENDWHILE

# WITH structure — written once, called twice
SUBROUTINE getValidMark(prompt)
    REPEAT
        OUTPUT prompt
        mark ← STRING_TO_INT(USERINPUT)
    UNTIL mark ≥ 0 AND mark ≤ 100
    RETURN mark
ENDSUBROUTINE

m1 ← getValidMark('Enter mark 1')
m2 ← getValidMark('Enter mark 2')

The structured version is shorter, and a fix to the validation applies everywhere automatically. In the unstructured version you would have to correct the same bug twice — and miss it once.

AQA tip. For "explain the advantages of the structured approach", the two strongest points are independent testing/debugging and reuse without duplication. Develop each with a consequence rather than listing five one-word advantages.