Students should be able to describe the structured approach including…

The idea

Structured programming means breaking a large problem into smaller, self-contained subroutines rather than writing one long block of code. Each subroutine should do one clear job, so the program is easier to read, test and fix. A modularised design lets you reuse a subroutine in several places and change it in one place only. The interface is how a subroutine connects to the rest of the program: it takes in parameters (the values passed in) and may give back a return value. Keeping variables local means they exist only inside the subroutine, so they cannot be accidentally changed elsewhere. Clear documentation, such as meaningful names and comments stating what each parameter and return value means, makes the interface understandable to other programmers.

For example: A function to work out an average might take a list of numbers as a parameter and return the mean as a value.

What earns the marks

• Explains that structured programming splits a problem into smaller self-contained subroutines or modules, each performing one clear task.
• States that modularised code is easier to read, test, debug, maintain and reuse because changes are confined to one module.
• Identifies the interface of a subroutine as its parameters (inputs) and return value (output), and explains that these define how other code uses it.
• Explains that local variables exist only within the subroutine, preventing unintended changes elsewhere and reducing errors.
• Describes documentation of the interface, such as meaningful names and comments explaining parameters and return values, so others can use the subroutine correctly.
• Gives a valid example, such as a function taking a parameter and returning a calculated value, to illustrate the structured approach.

Common mistakes and how to put them right

• Thinking structured programming means writing code in a fixed top-to-bottom order only.

  Put it right: It means decomposing the problem into reusable subroutines with clear interfaces.

• Confusing a parameter with a return value.

  Put it right: A parameter is a value passed into the subroutine, whereas a return value is the result the subroutine sends back.

• Assuming local variables can be read and changed anywhere in the program.

  Put it right: Local variables are only accessible inside the subroutine where they are declared.

• Treating documentation as optional decoration.

  Put it right: Documenting parameters and return values is part of making the interface clear and usable.

Exam tips

• Link each feature to a benefit: modular design to reuse and easier maintenance, local variables to reduced errors, documentation to clarity.
• When asked to describe, give the feature and then say what it achieves, rather than just naming it.
• Use a short concrete example of a subroutine with a parameter and a return value to make your description precise.