Procedures and Functions
Programming · 4 question types
Exam Frequency Analysis
Past paper frequency (2018 to 2024)
This topic accounts for approximately 4% of your exam marks.
Writing and calling procedures/functions with parameters is tested in Paper 2.
The of a variable is where in the program that variable can be seen and used.
A variable's scope depends on where it is declared. Two common scopes:
- Local scope: the variable is visible only inside a particular sub-program or block.
- Global scope: the variable is visible everywhere in the program.
Local variables
A local variable is one that is declared inside a (procedure or function). It only exists while that sub-program is running; once the sub-program returns, the local variable is destroyed.
Example:
PROCEDURE ShowDouble(Number : INTEGER)
DECLARE Doubled : INTEGER
Doubled ← Number * 2
OUTPUT Doubled
ENDPROCEDURE
CALL ShowDouble(7)
OUTPUT Doubled // ERROR: Doubled does not exist here
Doubled is local to ShowDouble. The main program cannot see it. As soon as the procedure ends, Doubled is forgotten.
Global variables
A global variable is one that is declared outside any sub-program, at the top level of the program. It is visible throughout the entire program, including inside sub-programs.
Example:
DECLARE Score : INTEGER
Score ← 0
PROCEDURE AddPoint
Score ← Score + 1 // can see the global Score
ENDPROCEDURE
CALL AddPoint
CALL AddPoint
OUTPUT Score // outputs 2
Score is declared at the top level, so any sub-program can read and update it.
Why prefer local variables when possible
Although global variables are convenient, using them too freely makes programs hard to maintain:
- A bug that changes a global value can affect parts of the program far away from where the bug is.
- Two sub-programs that happen to use the same variable name globally will accidentally interfere with each other.
- Reading a program with many globals requires holding the whole program in your head at once.
Best practice: use by default, and use and return values to pass information between sub-programs. Reserve globals for genuinely shared state, such as a running total or a configuration setting.
Side-by-side comparison
| Feature | Local variable | Global variable |
|---|---|---|
| Where declared | Inside a sub-program (procedure or function) | Outside any sub-program (top level) |
| Visible from | Only inside the sub-program that declared it | Anywhere in the program |
| Lifetime | Created when the sub-program starts; destroyed when it ends | Lives for the whole program run |
| Risk of accidental interference | Low: name clashes are local to the block | Higher: any code can change the value |
| Best for | Temporary calculations, loop counters, intermediate results | Shared state, configuration, totals across many sub-programs |
| Preferred style | Default choice | Use sparingly |
Spotting scope issues
Most scope mistakes show up in three patterns. Knowing the symptoms makes them easy to fix:
- A name appears to vanish. A variable assigned inside a procedure cannot be read by the main program afterwards. If the main program tries, the value is either zero, blank, or undefined. Fix by returning the value (use a function) or by writing to a genuinely shared global.
- Two variables share a name by accident. A procedure declares a local variable whose name matches a global. Inside the procedure, writes go to the local one; the global is left untouched. The bug looks like "the total never updates". Fix by renaming one of them, or by passing the value in as a parameter.
- A counter outlives its loop. A loop variable declared inside a procedure is destroyed when the procedure ends. Calling the procedure again starts the counter from scratch. If the intent was a running total across calls, the variable belongs at the top level as a global.
A quick rule of thumb: if a value is needed in only one block, declare it locally; if several sub-programs must share it, pass it as a parameter or return it. Reach for a global only when the value really is shared state for the whole program.