Procedures, parameters and reuse

By the end you can:

• Match arguments to parameters by position and trace a call that returns a value.
• Explain the difference between returning a value and displaying it.
• Refactor duplicated code into one procedure with parameters for what differs.
• Show with two calls that a parameter changes a procedure’s result, and recognise an ignored parameter.
• Choose a generalisation that preserves existing behaviour.

Procedure

A named group of instructions that can take parameters and return a value.

Parameter

A variable in a procedure’s definition that receives a value when the procedure is called.

Argument

The value passed into a parameter in a particular call.

Return value

The value a procedure gives back to its caller with RETURN.

Procedural abstraction

Using a procedure by what it does, without needing to know how it does it.

Generalise

Replace a fixed value with a parameter so one procedure handles many cases.

A procedure is a named group of instructions that may take parameters and may return a value. When you call it, each argument you pass is matched to a parameter by position: the first argument goes to the first parameter, the second to the second.

1PROCEDURE fee(members, rate)2{3  RETURN(members * rate)4}56cost ← fee(4, 3)

In the call fee(4, 3), members gets 4 and rate gets 3. The procedure returns 12, and cost ← 12. Swapping the arguments would swap which parameter gets which value.

RETURN(value) ends the procedure and gives value back to the caller, which can store it or use it in an expression. DISPLAY(value) shows it to the user but gives nothing back.

If a later step needs the result — to add, compare or store it — the procedure must RETURN it.

Worked example

The club page and the room page each count capacities of at least some minimum. The code was copied, then one copy was fixed and the other was not.

1clubCount ← 02FOR EACH c IN clubCaps3{4  IF (c ≥ 3)5  {6    clubCount ← clubCount + 17  }8}910roomCount ← 011FOR EACH r IN roomCaps12{13  IF (r > 5)14  {15    roomCount ← roomCount + 116  }17}

The room copy uses > where the room rule says “at least 5”. Bugs like this appear because each copy must be fixed separately. Replace both with one procedure whose parameters carry what differs: the list and the minimum.

1PROCEDURE countAvailable(caps, minimum)2{3  count ← 04  FOR EACH c IN caps5  {6    IF (c ≥ minimum)7    {8      count ← count + 19    }10  }11  RETURN(count)12}1314clubCount ← countAvailable(clubCaps, 3)15roomCount ← countAvailable(roomCaps, 5)

1def count_available(caps, minimum):2    count = 03    for c in caps:4        if c >= minimum:5            count = count + 16    return count

A procedure generalises behaviour only when its parameters are actually used. If countAvailable(caps, minimum) still compares with a fixed 3 inside, the minimum parameter is ignored: changing only minimum cannot change which values are counted. The procedure is not general with respect to that threshold.

1PROCEDURE countAvailable(caps, minimum)2{3  count ← 04  FOR EACH c IN caps5  {6    IF (c ≥ 3)7    {8      count ← count + 19    }10  }11  RETURN(count)12}

• One fix repairs every caller. Fixing countAvailable fixes the club page and the room page at once.
• Callers can be read at a higher level: countAvailable(roomCaps, 5) says what happens without showing how.
• New callers reuse tested code instead of copying it.

When you generalise an existing procedure, check that the old behaviour is still available. If the old countOver3(caps) counted values of at least 3, then countAvailable(caps, 3) must give exactly the same results.

• Displaying is the same as returning

  The belief: If the procedure shows the answer, the caller can use it.

  What is actually true: DISPLAY shows a value to the user; only RETURN gives it back for the caller to store or calculate with.

  Check yourself: Could you write x ← procedure(…) + 1 and get a number?

• Having a parameter makes a procedure general

  The belief: countAvailable(caps, minimum) is general because it has a minimum parameter.

  What is actually true: The parameter must be used in the body. If minimum is ignored, changing only that argument cannot change the result.

  Check yourself: Do two calls with different minimums ever give different results?

• Arguments match parameters by name

  The belief: The argument called minimum goes into the parameter called minimum wherever it is.

  What is actually true: Arguments are matched by position, not by name.

  Check yourself: Which parameter is first in the definition, and which argument is first in the call?

1. Call countAvailable([4, 4, 1], minimum) with two different minimums that give different results, and explain the difference.
2. Explain why a procedure that ends with DISPLAY(count) cannot be used in total ← countAvailable(a, 3) + countAvailable(b, 3).

Practice only: answers are checked in your browser and nothing is saved or sent to your teacher. Each explanation links back to the section it practises.

Lesson practice

Apply it somewhere new