Subroutine Studio
Two kinds of named block, told apart by what the caller actually wants. Plus the reason local variables are a gift rather than a nuisance, and the everyday function you have been using without noticing.
Get the method right under pressure
Free interactive practice on the steps that lose marks under exam pressure.
Start revising freeWhat you'll cover
Give the work a name
Everybody learns that you should break a program into smaller named pieces, and almost everybody, asked why, says "reusability" and stops. ⚠️ That is a word, not a reason, and on its own it earns very little.
Here are three reasons that actually hold up.
It is written once and fixed in one place. If the same calculation is copied into four places and turns out to be wrong, it is wrong in four places and you will find three of them.
The name does the explaining. A program built from calls like calculateTotal and printReceipt can be followed without opening either of them. Detail is available when you want it and out of the way when you do not.
Each piece can be tested on its own, which is far easier than testing a program where everything is tangled together.
This module is about the two kinds of named piece, what you can pass into them, and the rules about which variables they can see.
Words for subprograms
Six terms. The last two are about what a subprogram is allowed to SEE, which is the part most people get wrong.
Called for what it hands back, or for what it does
Both are named blocks you can call. The useful question is not what they are but why anyone would call one.
How to justify a named piece
Two kinds of question come up here and each has a shape. ⚠️ When you are asked WHY a program is broken into named pieces, do not write "reusability" and stop. Give a reason that says what it buys: written once so it is fixed in one place, named so the rest of the program can be followed without reading it, or testable on its own. Any one of those, stated properly, beats the word. ⚠️ When you are asked WHICH KIND to use, answer from what the caller needs afterwards - a value it can go on to use, or a job that has now been done. That single question settles it every time, and it is much more reliable than trying to remember two definitions under pressure. A weak answer describes the two kinds. A strong answer says what this particular caller wanted and picks accordingly.
Match each part to what it is
- A subprogram that hands a value back to whatever called it
- A subprogram that carries out a job and hands nothing back
- A value passed in to a subprogram at the moment it is called
- A variable that exists only while its own subprogram is running
- a function
- a procedure
- a parameter
- a local variable
The result nobody caught
A program calls a subprogram that works out a total and hands it back. The line making the call does not store the returned value or use it for anything. What does that tell you?
- Either the value should have been stored and used, or the job never needed to hand anything back in the first place
- Nothing in particular, since using a returned value is always optional
- The subprogram will fail, because its result was not collected
- It means a parameter was passed in incorrectly
Why local is a feature
A local variable exists only while its own subprogram is running and cannot be seen from anywhere else. Stated like that it sounds like a restriction being imposed on you. ⚠️ It is the exact opposite, and this is worth understanding rather than memorising.
Imagine writing a subprogram for a program you have never seen. You need a working variable, and you call it count.
If variables were visible everywhere, you would have to know that nothing else in that program uses the name count. And you cannot know that. Nor could anybody writing another subprogram know about yours. Every name would have to be agreed across the whole program by everyone who ever touched it.
⚠️ Local scope means nobody has to have that conversation. Your count and theirs are different variables that happen to share a name, and neither one can disturb the other.
The global counterpart is the honest reverse. A global variable is visible everywhere, which also means it can be changed from anywhere. That is occasionally exactly what you want, and it is usually the reason somebody spends an afternoon hunting a wrong value that could have been written by any line in the program.
The rule worth carrying: keep every variable as local as it can be.
True about scope
Select the TWO statements that are true.
- A local variable cannot be seen from outside the subprogram it belongs to
- Two different subprograms can each have a local variable of the same name without clashing
- A global variable exists only while the program is starting up
- Making every variable global makes a program easier to debug
Trace the call
A function named double takes one parameter and hands back twice its value. Trace the two calls and fill in what each one returns.
The function you already use
There is one function on this specification that you have almost certainly used without ever calling it a subprogram: a random number generator. You ask it for a whole number within a range - say 1 to 6, like a dice - and it hands one back. ⚠️ Look at what that sentence contains. You pass in what it needs, which is the range. It hands back a value. And the value is the entire point of calling it - a random number nobody catches has achieved precisely nothing. That is a function, described in one sentence, and it is worth keeping as your mental example of one. ⚠️ The range matters and questions test it. Ask for 1 to 6 and there are six possible results, one of which may be 6. Ask for 1 to 5 and 6 has become impossible. Throughout this module a requested range INCLUDES BOTH ENDS - languages differ on that point, so say which you are assuming if a question leaves it open.
How many values could come back
A random number function is asked for a whole number from 1 to 6, with both ends of the range included, as on a dice. Work out how many different values it could hand back.
Complete the subprogram paragraph
A named block of code that carries out a job and hands nothing back is a _____. One that hands a value back to whatever called it is a _____. A value passed in at the moment the call is made is a _____. A variable that exists only while its own subprogram is running is a _____ variable, while one visible right across the whole program is a _____ variable.
Procedure or function
Five in a row, three lives. Decide from what the caller wants back, not from the name.
Spot the true subprogram facts
Tap the TWO statements that are true.
- A local variable cannot be seen from outside the subprogram it belongs to
- A function is worth calling for the value it hands back
- A procedure hands a value back to whatever called it
- Two subprograms cannot both use the name count for a local variable
Three design calls
Three decisions. Each answer has to carry the reason as well as the choice.
- A program has to work out the tax on a price in several different places, and each place then needs to display that figure. Which kind of subprogram, and why?
- A subprogram needs to work on a whole list of marks rather than on one mark at a time. What gets passed to it?
- A classmate declares every variable in their program as global, "so that everything can see them". What is the problem with that?
Explain subprograms, scope and what gets passed
A friend has written one enormous program with no named blocks at all, and every variable global. Write them the answer that explains what to change and why.
- Explain the difference between the two kinds of subprogram, in terms of what the caller wants afterwards
- Give two solid reasons for breaking a program into named pieces, without relying on the word reusability by itself
- Explain what a local variable is, and why limiting where it can be seen helps rather than hinders
- Explain what a parameter is, and say what this specification allows to be passed as one besides a single value
- Finish with the random number generator as your example, saying which kind of subprogram it is and how you know