4. The Function

Lesson 4 extension · judge the boundary, not the line count

What has the function promised, and to whom?

Repeated code is easy to see, so removing repetition is often the first reason given for creating a function. It is a useful reason, but it is not the deciding one. Six repeated lines may belong to one operation, two different operations or no useful operation at all. Extracting them changes the shape of the program; it does not prove that the new shape is better.

The stronger test is the boundary the function creates. Its name and declaration should tell the caller what operation is available, which values must cross into it and what comes back. Its body must then honour that account. If a reader has to inspect the body to discover a hidden input or an unexpected change elsewhere in the program, the boundary has concealed a responsibility rather than controlled it.

This is why a function is more than a convenient container for statements. It is the first practical unit in which we can separate a claim from the evidence for that claim. The declaration makes the claim. The body supplies the evidence. Tests can then ask whether the evidence holds for the cases the function promises to handle.

A call is a sequence, not a mysterious jump

#include <iostream>

int square(int value) {
    return value * value;
}

int main() {
    const int sideLength{6};
    const int area{square(sideLength)};
    std::cout << "Area: " << area << '\n';
}

Begin at the call site. In square(sideLength), sideLength is the argument expression and its value is 6. The call creates and initialises the parameter object value for this invocation. Because this parameter is passed by value, value is a separate object. Changing it inside square would not change sideLength.

Control enters the function body. The expression value * value produces 36, and the return statement supplies that value to the call expression. The expression square(sideLength) therefore has the value 36, which is used to initialise area. The parameter value reaches the end of its lifetime when this call finishes, and control continues in main.

The distinction between an argument and a parameter is not decorative terminology. The argument belongs to the caller. The parameter belongs to this invocation of the function. That distinction becomes essential when the course reaches copying, references and ownership. If the two words are treated as synonyms now, later explanations will have no precise way to say which object changed.

A returned value is also not printed output. square returns an integer to its caller and performs no input/output. main chooses to print the result. Replace the console with a graphical interface or a test, and the calculation remains usable because it has not acquired a printing side effect. Seeing 36 on the screen proves that some output occurred; it does not, by itself, prove that square returned 36 to its caller.

A compiler may inline a small function, but that implementation decision does not alter this semantic account. We still reason about an argument, a parameter, a body and a returned value. Performance is measured against a real program and a real requirement. It is not guessed from the mere presence of a function call.

Read the declaration as a partial contract

A declaration gives important evidence, but not the whole contract. For a small function, force the missing parts into the open with three questions:

1. What must be true about the arguments when the function is called?
2. What value or observable effect does the function promise?
3. Which state, if any, is the function permitted to change?

Now test square against the type it advertises. On an implementation where a 32-bit int has a maximum value of 2,147,483,647, the mathematical result of square(50'000) is 2,500,000,000. The call is well-formed, but the signed multiplication overflows and C++ does not define the resulting behaviour. Successful compilation has proved the syntax and type checks that the compiler performed. It has not proved that the operation is valid for every int value.

The real design must therefore decide what the accepted input range is and how failure is represented. The function could reject an unsuitable value, use a wider checked representation or return an explicit failure. Until that decision is made, int square(int value) describes the types crossing the boundary but overstates the safe mathematical operation.

Return types require the same care. Suppose save_game() returns void. That does not mean nothing happened. The function may open a file, write bytes and update error state before returning no value. Those observable effects belong in its contract. Conversely, a function named calculate_score() that also resets the current level carries out an action its name and return type fail to admit. The caller needs to know what changes, not merely what comes back.

Coherence matters more than a preferred size

Line count is a proxy. A six-line function can mix unrelated decisions, while a longer function can still express one coherent operation at one level of abstraction. I want to know whether the function has one responsibility that can be named, tested and understood without keeping the whole program in mind.

process() tells me almost nothing. load_level_description() makes a narrower claim, but a better name cannot rescue a confused body. If the only honest name contains "and", that is evidence that two responsibilities may have been forced together. It is evidence, not an automatic splitting rule: the body and its effects decide the matter.

Every split creates an interface. A parameter carries an admitted dependency into the function. A return value or side effect carries an outcome out. A read from a hidden global is still a dependency, only one that the declaration has failed to reveal. Creating the greatest possible number of tiny functions would merely replace one kind of confusion with another. The useful decomposition is the one that makes important decisions visible and keeps each boundary truthful.

Generated code should be judged in this order as well. Begin with the proposed declarations. Do the boundaries match the responsibilities in the problem? Can every required input and every permitted mutation be accounted for? Is the promised result testable? Only then inspect the bodies. Elegant statements behind the wrong interface still produce the wrong design.

Test the two sides of the boundary

Choose one function declaration from the lesson. Without opening its body, write four short statements: what the caller supplies, which parameter objects are initialised, what value or effect is promised, and what other state may change. Then inspect every read, write and return in the body. Mark each place where the implementation requires more than the declaration and surrounding explanation admitted.

Finish by tracing two calls to square, first with 6 and then with 7. Give each invocation its own parameter object and follow each returned value to its destination. If your trace cannot distinguish the caller's argument from the callee's parameter, repair the vocabulary before adding more code. The purpose of the exercise is not to recite four function parts. It is to show that the claim at the boundary and the work inside it agree.