Key vocabulary

Matching values to a sub-program's inputs

What is a formal parameter?

A formal parameter is the name written inside a sub-program's own definition to represent one of its inputs. In def isAffordable(price, budget):, both price and budget are formal parameters — they are placeholders, existing only to describe what kind of input the function expects and how that input will be referred to inside the function's own code. A formal parameter has no value of its own until the sub-program is actually called.

What is an actual parameter?

An actual parameter is the real value or variable supplied at the point where a sub-program is called. In the call isAffordable(75, 100), 75 and 100 are actual parameters — real data being handed into the function for this particular call. An actual parameter does not have to be a literal value like 75; it can equally be a variable, such as isAffordable(itemPrice, budgetLimit), or even an expression, such as an element of a record like itemRecords[2]. Whatever form it takes, its role is the same: supplying one real input for this specific call.

How actual parameters are matched to formal parameters

Actual parameters are matched to formal parameters by position, not by name. The first actual parameter in a call is matched to the first formal parameter in the definition, the second actual parameter to the second formal parameter, and so on. This is exactly why calling isAffordable(75, 100) sets price to 75 and budget to 100 — not because the names "match" in any way, but purely because of the order in which the values appear. The formal parameter's name and the actual parameter's name (if it has one, as with a variable) never need to be the same, and usually are not.

Why this matters when tracing code

Because matching is entirely positional, swapping the order of two actual parameters in a call silently changes what each formal parameter receives, without causing any error — the code still runs, it just runs on the wrong data. This makes parameter order a genuine source of quietly incorrect programs, and a common focus for exam questions that ask you to trace through a call and state what a sub-program actually receives and returns.

This links back directly to SDD7's idea of modular design. A function or procedure is only reliable as a reusable building block if every call site supplies its actual parameters in the correct order — the sub-program itself has no way of checking whether the values it receives make sense for the names it was given, since by the time it runs, the formal parameters are simply bound to whatever values arrived in whatever order they arrived. Careful, consistent ordering at every call site is therefore part of writing dependable modular code, not a minor detail.

Formal and actual parameters, side by side

In isAffordable(75, 100) calling def isAffordable(price, budget): — the first actual parameter (75) is matched to the first formal parameter (price), and the second actual parameter (100) to the second formal parameter (budget), purely by position.

Worked examples

def isAffordable(price, budget):
    return price <= budget

isAffordable(75, 100)

itemPrice = 90
budgetLimit = 80
isAffordable(itemPrice, budgetLimit)

def isInStock(record):
    return record.stock > 0

isInStock(itemRecords[2])

def calculateChange(amountPaid, price):
    return amountPaid - price

calculateChange(100, 75)

Task Set A — Core questions

def isAffordable(price, budget):
    return price <= budget

isAffordable(75, 100)

def calculateChange(amountPaid, price):
    return amountPaid - price

calculateChange(100, 75)

Task Set B — Extension