Calling Procedures: Study Guide (Computer Science Principles 3.12)

You use procedures every day without noticing. When you press “send” you do not think about how the message is packed up and delivered; you just call on that service. In programming, a procedure is a named group of instructions that you can call whenever you need its job done. This topic is about using procedures: how a call works, what parameters and arguments are, how a procedure gives a value back, and how to trace the flow of control when a program jumps into a procedure and out again. Topic 3.13 then shows how to write your own.

Notation. The exam uses its own pseudocode, not a real programming language. The code in this pack is Marlbridge’s rendering of that reference notation, not a copy of the official sheet: ← is assignment, = tests equality, lists start at index 1, DISPLAY shows a value, and braces mark blocks. Use the Exam Reference Sheet from your teacher for the official wording.

What a procedure is

A procedure is a named group of programming instructions. It may have parameters and it may return a value. Different languages call procedures by different names, such as method or function; the exam uses “procedure”.

Two words are easy to mix up:

• A parameter is an input variable of the procedure, named where the procedure is defined.
• An argument is the actual value supplied for a parameter when the procedure is called.

In PROCEDURE rectArea(width, height) the names width and height are parameters. In the call rectArea(3, 4) the values 3 and 4 are arguments: 3 is assigned to width and 4 to height, in order.

Calling a procedure and the flow of control

A procedure call interrupts the sequential execution of statements. The program jumps into the procedure, runs the statements inside it, and when the last statement (or a RETURN) has executed, flow of control returns to the point immediately following the call, and the program carries on.

The notation for a call is procName(arg1, arg2, ...), with zero or more arguments. A procedure can be used in two ways.

1. As a statement. The call stands on its own line and only its effect matters, such as displaying something.
2. As an expression. The call produces a value that is used straight away, for example result ← procName(arg1, arg2), or inside a larger expression, total ← price + tax(price). The call is replaced by the returned value before the rest of the line is evaluated.

Tools the reference sheet provides

Procedure	What it does	Example
DISPLAY(expression)	Shows the value of the expression, followed by a space	DISPLAY(a + 1)
INPUT()	Accepts a value from the user and returns it	n ← INPUT()
RETURN(expression)	Inside a procedure: sends a value back to the caller and ends the procedure immediately	RETURN(width * height)
RANDOM(a, b)	Returns a random integer from a to b inclusive (Topic 3.15)	RANDOM(1, 6)

Notice the difference between displaying a value and returning one. DISPLAY shows something to the user and gives nothing back to the program. RETURN gives a value back to the program (the caller) and displays nothing. Mixing the two up is a classic error.

Worked example 1: tracing calls

Trace this program and state what is displayed.

PROCEDURE rectArea(width, height)
{
  RETURN(width * height)
}
a ← rectArea(3, 4)
b ← rectArea(a, 2)
DISPLAY(a + b)

Output: 36

Step	What happens	Values
1	Definition. The program only records the procedure; nothing runs yet.	–
2	rectArea(3, 4): width = 3, height = 4. RETURN(3 * 4) gives 12. a ← 12.	a = 12
3	rectArea(a, 2): a is 12 so width = 12, height = 2. Returns 24. b ← 24.	b = 24
4	DISPLAY(a + b) shows 12 + 24.	36

Check. The result 36 is plausible: 12 + 24. A slip would be to treat width and height as variables that already exist in the main program; they exist only while the procedure runs.

Order of arguments matters. Arguments are matched to parameters by position. With PROCEDURE diff(first, second) { RETURN(first - second) }:

PROCEDURE diff(first, second)
{
  RETURN(first - second)
}
DISPLAY(diff(10, 4))
DISPLAY(diff(4, 10))

Output: 6 -6

Swapping the arguments swaps first and second, so the result changes sign.

Worked example 2: side effects, early return and flow of control

A procedure can have effects (such as displaying) as well as a returned value. This one also uses RETURN early.

PROCEDURE check(n)
{
  IF(n < 0)
  {
    DISPLAY("negative")
    RETURN(0)
  }
  DISPLAY("ok")
  RETURN(n * 2)
}
x ← check(5)
y ← check(-3)
DISPLAY(x + y)

Output: ok negative 10

Step	Call	Inside the procedure	Returned	Displayed so far
1	check(5)	5 < 0 is false, so skip the IF. Display ok. RETURN(5 * 2)	10	ok
2	x ← 10			ok
3	check(-3)	-3 < 0 is true: display negative. RETURN(0) leaves immediately; the lines after it do not run	0	ok negative
4	y ← 0
5	DISPLAY(x + y)			ok negative 10

Check. The two displays inside the procedure happen during the calls, before the final DISPLAY. A RETURN ends the procedure at once, so the line DISPLAY("ok") is not reached when n is negative. Notice also that a procedure call is complete before the next statement begins: the program never “goes back” into a procedure it has finished.

Taking input. INPUT() is a procedure that returns a value typed by the user. With the user typing 7:

n ← INPUT()
DISPLAY(n * 2)

Output: 14

The call is replaced by the value returned (7), which is stored in n.

Reading a call correctly

Use this checklist whenever a procedure call appears in code.

1. Find the definition and write down its parameters in order.
2. Match the arguments to the parameters by position and record the values.
3. Run the body with those values, tracking any DISPLAY output.
4. Note the returned value, if any. A call that returns a value is replaced by it.
5. Resume at the point just after the call, using the returned value in the expression.

A procedure is also a form of abstraction: you can call rectArea without knowing how it multiplies. That idea, using a procedure only knowing what it does, is the heart of Topic 3.13.

Arguments and calls can be any expression

An argument does not have to be a plain value. It can be a variable, an arithmetic expression, a list or even another call; the program evaluates it first and then passes the result. A call that returns a Boolean can also be used as a condition, which keeps the decision readable:

PROCEDURE isEven(n)
{
  RETURN(n MOD 2 = 0)
}
x ← 6
IF(isEven(x + 1))
{
  DISPLAY("even")
}
ELSE
{
  DISPLAY("odd")
}

Output: odd

Here the argument x + 1 is evaluated first (7), the call returns false, and the ELSE block runs. Naming the test isEven makes the IF read almost like English. This is one reason procedures help with clarity as well as with reuse.

Common misconceptions

• “Parameters and arguments are the same thing.” A parameter is the name inside the definition; an argument is the value in the call.
• “Arguments can be given in any order.” They are matched to parameters by position.
• “DISPLAY and RETURN do the same job.” DISPLAY shows a value to the user; RETURN gives a value back to the calling code and ends the procedure.
• “Code after a RETURN still runs.” A RETURN causes an immediate return to the call.
• “A procedure runs when it is defined.” It runs only when called.
• “Variables in a procedure’s body are the same as the caller’s variables.” Parameters are new variables that receive the argument values when the call is made.

Where this leads

Next, Topic 3.13 shows how to develop your own procedures with parameters, why procedural abstraction manages complexity, and how to explain it for the Create performance task.

Next steps: try the practice questions, skim the revision notes the night before, and tick off the topic checklist. The next topic is Topic 3.13, Developing Procedures.