Topic 3.13 Notes – Developing Procedures

1. What Procedural Abstraction Is

A procedure is a named group of statements that performs a task.

Procedural abstraction means you can use that procedure by knowing what it does, without needing to know how it does it.

Think about DISPLAY(). You use it to show output. You do not know the internal code that makes text appear on a screen. You only rely on its behavior.

That’s the key idea:

• Name the process
• Hide the details
• Expose the purpose

This helps with big problems. Instead of writing one giant block of code, you:

• Identify smaller tasks.
• Write a procedure for each task.
• Combine them to solve the larger problem.

If your program calculates grades, you might have:

• One procedure to calculate an average
• One to determine a letter grade
• One to display results

The large solution is built from smaller ones. That is how abstraction manages complexity.

2. Modularity and Breaking Problems into Subproblems

When you divide a program into separate subprograms, that’s called modularity.

Think of a large system broken into modules, and each module broken into smaller components. Each small piece handles one specific job, and the pieces work together to form the whole program.

Modular program structure with modules and components

Each smaller box in the diagram represents a procedure solving one subproblem.

Why this matters:

• Testing is easier
  You can test one procedure at a time.
• Debugging is easier
  If output is wrong, you check the specific procedure responsible.
• Teamwork becomes possible
  Different people can write different procedures.
• Programs are readable
  A procedure name like calculateTotal is clearer than 15 lines of math.

On AP questions, they love showing repeated blocks of similar code. The better design is almost always to turn that repeated logic into a procedure.

3. Defining and Calling Procedures

The exam reference sheet gives you this structure.

Procedure Without Return

PROCEDURE greetUser(name)
{
    DISPLAY("Hello")
    DISPLAY(name)
}

Calling it:

greetUser("Maya")

Important vocabulary:

• Parameter → the variable in the definition (name)
• Argument → the actual value passed in ("Maya")

This type performs an action but does not send back a value.

Procedure With Return

Some procedures calculate something and send a result back.

PROCEDURE square(num)
{
    RETURN(num * num)
}

Using it:

result ← square(4)
DISPLAY(result)

Two critical rules:

• RETURN(expression) sends a value back.
• As soon as RETURN runs, the procedure stops immediately.

Example with early return:

PROCEDURE checkScore(score)
{
    IF(score ≥ 90)
    {
        RETURN("A")
    }
    RETURN("Not A")
}

If the condition is true, the second RETURN never runs. This is a common AP trick.

4. Parameters and Generalization

Without parameters, you would need many similar procedures:

PROCEDURE add5()
PROCEDURE add10()
PROCEDURE add20()

That’s messy and repetitive.

With parameters:

PROCEDURE addNumber(value, amount)
{
    RETURN(value + amount)
}

Now one procedure handles many cases.

This is called generalizing functionality:

• Extract shared logic
• Replace specific values with parameters
• Reuse the procedure with different arguments

Benefits:

• Less duplicated code
• One place to fix bugs
• Cleaner structure
• Works for a range of inputs

On Create Performance Task responses, when you explain how your procedure manages complexity, mentioning generalization through parameters earns you stronger reasoning.

5. Why Procedural Abstraction Matters

Procedural abstraction improves programs in several ways.

Code Reuse

Write it once. Call it many times.
If you change the procedure, every call automatically uses the updated version.

Readability

Procedure names act like summaries.
calculateTax(price) is easier to understand than reading the full formula every time.

Maintainability and Flexibility

You can improve the inside of a procedure:

• Make it faster
• Use less memory
• Clean up logic

As long as the behavior stays the same, the rest of the program does not need to change. Users of the procedure don’t even know it was updated.

This is a huge idea on the AP exam. They often describe changing internal code but preserving functionality. That is still valid procedural abstraction.