Subroutines, Parameters and Local Variables
Why Break Code into Subroutines?
As a program grows, writing everything in one long block becomes unmanageable. A subroutine is a named, self-contained block of code that carries out one clear job. You call it by name whenever you need it, rather than writing the same code again. This makes programs shorter, easier to read, and much simpler to fix.
Breaking a large program into subroutines is called the structured approach. Professional software teams rely on it daily. A large system is built from many small modules, each handling one task. If a bug appears in the module that checks dates, engineers fix that module alone without touching the rest of the system.
Subroutines make programs easier to write (tackle one task at a time), easier to test (check each block in isolation), easier to reuse (call the same subroutine many times), and easier to maintain (change one block without breaking others).
Procedures and Functions
Subroutines come in two forms. A procedure performs a task and then simply stops — it does not hand a result back. A function performs a task and returns a value to the calling code. That returned value can be stored in a variable or used directly in an expression.
A classic example: a procedure might display a welcome banner on screen (it acts, produces output, and finishes). A function might calculate the total cost of a shopping basket and return the number so the rest of the program can display it, compare it to a budget, or store it in a database.
Here is a procedure that prints a greeting. It takes one parameter and carries out an action — no value is returned.
SUBROUTINE greetUser(name)
OUTPUT "Hello, " + name
ENDSUBROUTINE
greetUser("Priya") // outputs: Hello, Priya
Here is a function that calculates the area of a rectangle. It takes two parameters and hands the result back with RETURN.
SUBROUTINE calculateArea(width, height) area ← width * height RETURN area ENDSUBROUTINE result ← calculateArea(5, 3) OUTPUT result // outputs: 15
Both use the same SUBROUTINE … ENDSUBROUTINE keyword pair. The only structural difference is the RETURN statement in the function.
Parameters
A parameter is a variable in the subroutine’s definition. When you call the subroutine, you pass in values that fill those parameter slots. The values travel into the subroutine and are available inside it for the duration of the call.
A subroutine can have more than one parameter. For instance, a subroutine that checks whether a student’s score lies within a valid range needs both the score and the maximum allowed score — two parameters. The order you list the parameters in the definition must match the order you pass values in the call.
In exam material, the word parameter is used for both the variable in the subroutine definition and the value passed in at the call. You do not need to distinguish between “parameter” and “argument” in your answers.
Return Values
A function sends a value back to the calling code using RETURN. Once the program reaches the RETURN statement, the subroutine ends and the returned value replaces the function call in the expression. You can assign it to a variable, pass it straight into another calculation, or use it in a condition.
A common exam task is to trace what a function returns for given inputs. Work through the body of the function step by step, substituting the parameter values, until you reach RETURN.
Local Variables and Scope
Scope describes which parts of a program can see and use a particular variable. A local variable is created inside a subroutine. It springs into existence when the subroutine is called and is destroyed when it finishes. Nothing outside the subroutine can read or change it.
A global variable is declared outside all subroutines and is visible everywhere. That sounds convenient, but it creates serious maintenance problems in large programs: any part of the code can accidentally change a global, and tracking down where an unexpected change happened becomes very difficult.
Consider a banking app with a global variable called balance. Every subroutine — withdrawals, interest calculations, fee deductions — can modify it. If the balance ends up wrong, the programmer must check every single subroutine to find the fault. Using a local variable that is passed in as a parameter and returned means only that subroutine can change it. The problem is isolated immediately.
Local variables also save memory. They exist only while the subroutine is running. When a hundred users are simultaneously running the same login check, each gets their own isolated local copy of the username and password — they cannot interfere with each other’s data.
Good practice: declare variables local wherever possible. Use globals only for values that genuinely need to be shared across the whole program (for example, a configuration setting loaded once at start-up).
The Structured Approach in Practice
The structured approach means dividing a program into subroutines with clear, documented interfaces. Each subroutine receives its inputs through parameters, does its specific job, and returns any output through a return value or by modifying nothing beyond its local variables. This makes individual subroutines independently testable: write a subroutine, test it with known inputs, verify the output, and move on. If a later change is needed, you alter one well-labelled block rather than hunting through thousands of lines.
In an exam, if you are asked to write a subroutine, start with the signature (name and parameters), then write the body, then add RETURN at the end if it is a function. Parameter passing and return values are exactly what these questions test — do not leave them out.