Unit 6: Functions & Decomposition

Copy and paste can make a program longer. It cannot make the responsibilities clearer.

Functions let you create named boundaries around behavior. Those boundaries become useful when they define what goes in, what comes back, what state can change, and who is responsible for the job.

From repeated lines to a contract

You will begin by extracting repeated or conceptually related behavior into functions. Then you will add parameters, return values, local variables, and scope reasoning.

A useful function can often be described before its implementation:

name: calculate_average
inputs: collection of numeric scores
returns: one numeric average
side effects: none
failure boundary: empty collection must be handled deliberately

That description is a function contract. It gives you something to test and something another developer can reason about without reading the whole body first.

Decompose a real program

Your Unit artifact should contain multiple functions whose responsibilities are meaningfully different. Keep one call trace showing how execution moves from the caller into a function and back, plus one example where a return value is used by later code.

If every function is a one-line wrapper with a vague name, decomposition has not improved the design. The final question is simpler: did the boundaries make the program easier to understand, test, or change?