3.13 Developing Procedures

What you need to know

• Procedural abstraction lets a programmer use a procedure by knowing what it does without knowing how. The name and parameters are the interface; the body is hidden detail.
• Benefits: reduces duplicated code, makes programs easier to read and maintain, and lets you fix a bug in one place instead of many.
• Parameters generalize a procedure. A procedure that only works on one hardcoded value is far less useful than one that takes that value as a parameter.
• Good procedure names describe the task (calculateTax, isValidEmail). Like variable names, they're documentation.
• Create Task requirement: a student-developed procedure with at least one parameter that affects its behavior, and whose body includes an algorithm with sequencing, selection, and iteration. You must show the procedure being called, too.
• Procedures can call other procedures, building larger behavior from smaller verified pieces.
• A procedure should do one clearly defined thing. If you're describing it with "and," it may be two procedures.

Worked example

Without a procedure, computing a letter grade three times means the IF/ELSE chain appears three times. With one:

PROCEDURE letterGrade(score)
{
    IF (score ≥ 90) { RETURN ("A") }
    IF (score ≥ 80) { RETURN ("B") }
    IF (score ≥ 70) { RETURN ("C") }
    RETURN ("F")
}
DISPLAY(letterGrade(91))
DISPLAY(letterGrade(74))

Output: A C. If the school changes the B cutoff, you edit one line. That's the maintenance benefit the CED describes.

Going deeper

The nuance, edge cases, and connections that turn a 3 into a 5.

• Procedural abstraction in the CED: a procedure lets you use a computation by name without knowing (or re-reading) how it works. Once isPrime(n) is written and tested, you call it and trust it. That trust is the abstraction.
• The Create Task's procedure requirement is specific: a student-developed procedure with a name, a return type (or no return), and at least one parameter that has an effect on the procedure's functionality. The body must contain an algorithm with sequencing, selection, and iteration. And you must show a call to it.
• "Parameter that has an effect" means the parameter is actually used inside and changes what happens. A parameter that's received and ignored doesn't count.
• Generalization is the reason for parameters: greetRam() can only do one thing; greet(name) can do infinitely many. When code is duplicated with small variations, the variations become parameters and the code becomes one procedure.
• Procedures make programs easier to modify (change the body once), easier to test (test the procedure alone with known inputs), and easier to read (a good name explains the intent). The exam's "why use a procedure" questions want one of these.
• A procedure should have a single, clear purpose reflected in its name. calculateAverage should calculate an average and nothing else. Mixing responsibilities makes procedures harder to reuse.
• Procedures reduce duplicated code. Duplication is bad because a bug in duplicated code must be fixed everywhere it appears — and one copy inevitably gets missed.

Mistakes that cost points

• A Create Task procedure with a parameter that isn't used. Doesn't meet the requirement. The parameter must affect behavior.
• Choosing an efficiency reason for using a procedure. Procedures don't make programs faster. They make them clearer and easier to maintain. Options claiming speed or memory benefits are distractors.
• Not showing the call. The Create Task needs the procedure and a call to it in your code. A defined-but-never-called procedure doesn't count.

Practice questions

Written in the style of the real exam. Try each one before revealing the answer.