Programming structure

This module covers how a program is organised: the type of each value, where each variable can be seen, how to package code into subroutines with parameters, what a function returns, and why calculation is kept apart from input and output. These ideas sit behind every algorithm question.

Read the Cambridge IGCSE Computer Science syllabus page for the scope and notation of your exam year. The 2029 changes page explains how to check which version applies to you. This module belongs to the wider Computer Science learning guide.

What should I already know?

You need to read simple pseudocode: assignment, IF, and a FOR loop. If tracing a loop is new to you, practise a few short traces first. No earlier module is a strict requirement, but the hardware and processing module helps with why programs are written for a processor to follow step by step.

Orienting example: one function, four ideas

Here is a short function. Read it for structure, not just output.

FUNCTION TotalWithTax(Price : REAL) RETURNS REAL
    RETURN Price * 1.08
ENDFUNCTION

OUTPUT TotalWithTax(50.00)

• Data type: Price is REAL because an amount of money has a fractional part.
• Parameter: Price is how the function receives its input. The argument is 50.00.
• Returned value: RETURN sends 50.00 × 1.08 = 54.00 back to the caller.
• Separation: the function has no INPUT or OUTPUT. The main program shows the answer, so the output is 54.00.

The function also has no global variables, so its scope is trivial. That small design is what the five lessons teach you to produce and to explain.

What order should I study the lessons in?

1. Choose an appropriate data type: every variable and parameter needs one.
2. Explain local and global scope: where a variable exists and who can use it.
3. Build a subroutine with clear parameters: package a task so it can be reused.
4. Trace a returned value: follow a function call to the value it sends back.
5. Separate logic from input and output: combine the habits into one clean design.

Then try the mixed practice set. The restricted pseudocode trace trainer and the safe Python reasoning sandbox both suit this module, and the mistake log and retest queue helps you track repeated slips.

Which traps catch students most often?

• Choosing a type by appearance. A code made of digits is text, not a number.
• Reading a local variable as global. A local variable disappears when its subroutine ends.
• Swapping arguments. Arguments match parameters by position, and a swap gives a wrong answer without an error.
• Returning too early. A RETURN inside a loop ends the function on the first pass.
• Putting INPUT and OUTPUT inside a calculating function. Keep them in the main program unless the question says otherwise.

How do I use the practice set?

Do the lessons first, then attempt the practice set without notes and write every trace table out. Compare your working with the answer row by row. The set ends with a routing table, so each wrong answer sends you back to one lesson, not the whole module.

If this topic still feels slippery after that, our online one-to-one Computer Science tuition can work through your own code with you.