Take your Gradebook from 3.10 and rebuild it out of procedures. Same behavior, but the tangled main program becomes about five readable lines — and you feel, first-hand, why procedures exist.
Open your 3.10 gradebook — you’re rebuilding it, not starting over. Keep 3.12 (def), 3.13 (return), and 3.14 (list parameters) handy. This is a refactor: change the structure, keep the behavior.
End of Week 3 in Programs. You’ve learned to write procedures; today you use them to tame a program you already wrote. This is the last rehearsal before the Create PT dress rehearsal in Week 5.
Rebuild your Gradebook so each statistic is its own procedure that takes the list as a parameter and returns its result. The main program just calls them and prints.
□ At least three procedures, each with a
list parameter (e.g. average(scores), highest(scores),
count_passing(scores, cutoff)).
□ Each procedure returns its value — no printing inside the helpers.
□ The main program is about five readable lines: make the list, call each procedure, print the results.
□ Same output as your 3.10 version — prove the refactor didn’t change the behavior.
Notice how the messy middle moves into the procedures, and the main program becomes almost English:
def average(scores): return sum(scores) / len(scores) def highest(scores): hi = scores[0] for s in scores: if s > hi: hi = s return hi def count_passing(scores, cut): c = 0 for s in scores: if s >= cut: c = c + 1 return c
grades = [88, 92, 75, 60, 45] print("avg:", average(grades)) print("high:", highest(grades)) print("passed:", count_passing(grades, 60)) # Read it top to bottom: it says # what it does, not how. The "how" # lives in the named procedures.
Hover or tap a line to light its twin. The logic didn’t vanish — it moved into well-named boxes. The main program now reads like a summary, and each helper can be tested on its own. For this data: avg 72.0, high 92, passed 4.
Run the refactored version on any list. The point isn’t new output — it’s that three tidy procedures produce the same report your sprawling 3.10 code did.
□ The refactored program (3+ procedures with list parameters, each returning its value, a short main).
□ The sentence, completed for one of your procedures:
“My procedure ______ takes ______ and returns
______ so that ______.”
That sentence is Create PT written-response training in its purest form — name the procedure, its parameter, its return, and its purpose. If you can write it cleanly, you can write the PT response.
Don’t rewrite everything at once. Pull out
average() first, run the program, confirm the average still matches. Then extract
highest(), run again. One procedure, one test, every time. A refactor that breaks the
output isn’t a refactor — it’s a new bug.
Solo or paired — if you pair, the navigator’s job today is to check that behavior stayed identical after each extraction.
Write a single procedure lowest(scores) and then a
report(scores) that calls the other procedures and returns a formatted string
— a procedure built from procedures. Or make count_passing take the cutoff as a
second parameter (it already should) and call it twice with different cutoffs to show how
parameters make one procedure do many jobs.