Procedures package steps under one reusable name.
Write a block of instructions once, then call it whenever you need it.
A procedure is a named, reusable block of instructions. AP CSP uses the word procedure, though many programming languages call the same idea a function or method. You define the steps once, give them a name, and run them by calling that name.
This topic is part of Big Idea 3: Algorithms and Programming. You will learn how procedures reduce repeated code and support modularity and abstraction.
Why this matters: The Create Performance Task requires a student-developed procedure. Understanding procedures now prepares you to write and explain one later.
Define once, call many times.
A procedure hides detail behind a clear name.
A procedure has two parts: the definition, which lists the steps in the procedure body, and the call, which runs those steps. Defining a procedure does not run it; only calling it does.
Procedures bring two big benefits. Modularity means breaking a program into named, manageable pieces. Abstraction means you can use a procedure by its name without thinking about every internal step each time. Together they reduce repeated code and make programs easier to read.
If you find yourself writing the same lines in several places, that is a signal to move them into a procedure and call it instead.
A call runs the named procedure, which performs its steps and produces a result or action.
Read left to right: the call enters the procedure, the body runs its steps in order, and a result or action comes out. The same box can be reused by calling its name again. On the exam, remember that defining a procedure is separate from calling it.
The language of procedures.
Know the definition versus the call.
- Procedure: a named, reusable block of instructions (AP CSP term).
- Function: another common name for a procedure in many languages.
- Procedure call: running a procedure by its name.
- Procedure body: the steps inside the procedure.
- Modularity: building a program from separate named pieces.
- Abstraction: using a procedure by name without its internal detail.
Memory hook: Defining is writing the recipe. Calling is cooking it. You can cook the same recipe many times.
How procedures are tested.
Calls, reuse, and abstraction.
Be ready to:
- Trace what happens when a procedure is called.
- Explain how a procedure reduces repeated code.
- Recognize the benefits of modularity and abstraction.
- Tell the difference between defining a procedure and calling it.
The exam values understanding why procedures help, not just how they look. Connect them to managing complexity and enabling reuse.
Exam tip: When a procedure is defined but never called, none of its steps run. Look for the call, not just the definition.
A quiz app that shows feedback.
One procedure, called whenever needed.
A quiz app shows the same encouraging message after each correct answer. Instead of repeating the DISPLAY, it defines a procedure:
PROCEDURE showCorrectMessage()
{
DISPLAY("Correct! Great job.")
}
showCorrectMessage()
showCorrectMessage()The first block defines the procedure but does not display anything yet. The two lines after it are calls. Each call runs the body, so the program displays "Correct! Great job." twice.
The win here is reuse. If the message ever needs changing, you edit it once inside the procedure, and every call automatically shows the new text. That is modularity and abstraction working together.
Procedure pitfalls.
These reduce clarity or stop code from running.
- Defining but never calling. A procedure that is never called does nothing.
- Repeating code instead of reusing. Copy-pasted blocks should become one procedure.
- Unclear names. A name like doThing hides what the procedure does.
- Mixing unrelated tasks. Each procedure should do one clear job.
- Confusing definition with call. Writing the steps is not the same as running them.
Reframe: A procedure is a tool you build once. It only does work when you actually pick it up and use it (call it).
Procedure terms at a glance.
Definition, call, and benefits.
| Term | What it is | Example |
|---|---|---|
| Procedure | Named reusable block (AP CSP term) | showCorrectMessage |
| Function | Another name for a procedure | Same idea, other languages |
| Procedure call | Runs the procedure | showCorrectMessage() |
| Procedure body | The steps inside | DISPLAY("Correct! Great job.") |
| Modularity | Separate named pieces | One job per procedure |
| Abstraction | Use by name, hide detail | Call without reading the body |
Turn repeated lines into a procedure.
It is the heart of a strong Create Performance Task.
Whenever you notice the same steps appearing more than once, move them into a clearly named procedure and call it. This habit reduces errors, makes your program easier to explain, and directly supports the student-developed procedure required on the Create Performance Task.
Try it: Find a repeated action in a small program idea and rewrite it as a procedure you can call multiple times.
Practice — attempt these now.
AP-style assessments aligned to this lesson. Time them.