5 Functions and Program Structure

What Functions Do

Functions package instructions into named, reusable units. They help divide a complex problem into smaller tasks, reduce repeated code, and make programs easier to understand, test, and maintain.

A function commonly has four parts:

• A name that identifies its task.

• Parameters that receive input values.

• A body containing the instructions to execute.

• A return value when it produces a result.

In Python, def introduces a function definition, while a function call runs the function. A function should usually have one clear responsibility. For example, a function that calculates a total should not also display menus, read files, and update unrelated data.

A procedure is often described as a routine that performs an action without producing a useful value for its caller. The distinction depends on the programming language. In Python, every function technically returns a value: an explicit return provides the specified result, while reaching the end without return produces None.

Takeaway: Use functions to give focused tasks clear names and predictable responsibilities.

Inputs and Function Calls

The distinction between a parameter and an argument describes two sides of the same function call. A parameter is named in the function definition; an argument is supplied by the caller.

For example, in greet("Maya"), name can be the parameter and "Maya" is the argument. A function may accept multiple parameters, default values, and keyword arguments. Default values make some arguments optional, while keyword arguments associate values explicitly with parameter names.

Keep parameters focused and limited. Many unrelated parameters may indicate that a function is doing too many jobs. When a function receives a mutable object such as a list, operations inside the function may modify that object. Returning a new result is often easier to predict than changing shared data unnecessarily.

Takeaway: Define inputs clearly, use descriptive parameter names, and make changes to shared data explicit.

Return Values and Data Flow

A return value is the output of a function. Returning a value allows the caller to store it, compare it, display it, or pass it to another function. Printing a value only displays it; it does not provide that value to the caller in the same way.

For instance, a function that returns a doubled number can have its result assigned to a variable. A function that only prints the doubled number displays output, but an assignment from that call receives None.

A function can have several return paths, but each path should produce a meaningful and consistent kind of result whenever possible. The return statement also ends the current function immediately, so instructions after an unconditional return do not execute.

Return values support explicit data flow. A caller can use a returned result in a condition, combine it with other results, or send it to another function without relying on hidden state.

Takeaway: Prefer explicit results through return values over communication through printing or hidden changes.

Scope, Namespaces, and Encapsulation

Scope determines where a name can be accessed. A local variable is created inside a function and normally cannot be used outside that function. A global variable is defined at the module or program level and may be accessible from several functions.

Python creates a local namespace for each function call. If a function assigns message locally while a separate message exists outside the function, the two names refer to separate bindings. The local assignment does not automatically change the global value.

Local variables support encapsulation by protecting a function's internal state from unrelated parts of the program. Global variables should be used sparingly because global state can create hidden dependencies. A function may appear to depend only on its parameters while actually reading or changing data elsewhere.

A clearer design passes required data as parameters and returns results explicitly. This makes dependencies visible to callers and makes the function easier to test.

Takeaway: Keep internal state local when possible and make a function's required data and results visible through its interface.

Modular Design and Code Reuse

Modular design divides a program into independent, understandable components. A component may be a function, class, file, or package, and each component should have a clear purpose.

An interface describes how a component can be used. It includes:

1. The component's name.

2. The parameters it accepts.

3. The values or errors it can produce.

4. Important side effects, such as writing a file or changing a database.

Good modular design aims for high cohesion, low coupling, clear interfaces, and information hiding. High cohesion means that a component's responsibilities are closely related. Low coupling means that components depend on one another as little as practical. Information hiding keeps internal details inside the component that owns them.

For example, a grade-report program can use one function to calculate an average, another to determine a letter grade, and a third to assemble the report. Changing the grading scale then requires changing the grading function rather than rewriting the average calculation or report assembly.

Code reuse strengthens modular design. Instead of copying the same calculation into several places, define a descriptive function and call it wherever the related behavior is needed. Reuse reduces duplication and helps ensure that a correction is applied consistently.

Takeaway: Build components with focused responsibilities, explicit interfaces, and minimal unnecessary dependence on other components.

Decomposing Problems

Function decomposition turns a large problem into a sequence of smaller tasks. A practical process is:

1. State the overall problem.

2. Identify the major tasks needed to solve it.

3. Create one function for each focused task.

4. Define the data each function receives and returns.

5. Connect the functions in a main algorithm.

6. Test each function independently, then test the complete program.

A shopping program, for example, might separate reading items, calculating a subtotal, calculating a discount, calculating tax, and formatting a receipt. If the final total is wrong, each stage can be checked separately instead of debugging one large block of code.

A function should generally be short enough that its purpose and control flow can be understood without examining the entire program. Shorter is not automatically better, however. Splitting a simple operation into many meaningless functions can make a program harder to follow.

Takeaway: Decompose problems according to meaningful responsibilities, not merely according to line count.

Testing and Reliable Maintenance

Testing checks whether a program produces expected results for selected inputs. A unit test commonly follows four steps:

• Setup: Prepare the input or required objects.

• Execution: Call the function.

• Verification: Compare the actual result with the expected result.

• Cleanup: Remove temporary resources when necessary.

Choose test inputs that represent important behaviors:

• Typical values for ordinary cases.

• Boundary values at or near a limit.

• Empty values when empty input is permitted.

• Large values that may reveal performance or overflow problems.

• Invalid values that should produce an error or defined rejection.

Tests should check behavior rather than implementation details. For a number-classification function, useful cases include a positive number, a negative number, and zero. Python's unittest framework provides test cases, assertions, test suites, and test runners; methods whose names begin with test are recognized by the test runner.

Testing should be repeatable. When a bug is found, first add a test that demonstrates the bug. After changing the code, confirm that the new test passes and that existing tests still pass. This guards against regression, in which a later change accidentally breaks previously working behavior.

Takeaway: Test normal behavior, boundaries, empty and invalid inputs when relevant, and repeat tests after every significant change.

Design Review and Key Principles

Several recurring design problems make programs harder to understand and maintain.

• Functions that do too much: Separate input, calculation, state changes, and presentation when they represent different responsibilities.

• Hidden side effects: Avoid silently changing global data, files, or mutable inputs; document necessary changes.

• Unclear parameters: Use descriptive names instead of vague names such as data or value when the context is not obvious.

• Repeated code: Extract genuinely common behavior into a reusable function, but avoid abstractions that group unrelated operations.

• Insufficient tests: Include boundary and invalid cases instead of testing only one ordinary input.

A strong overall design combines focused functions, explicit inputs and outputs, limited global state, clear interfaces, code reuse, and repeatable tests. These practices make a program easier to trace, modify, and verify.

Takeaway: Good structure is the combined result of clear responsibilities, visible data flow, controlled side effects, and tests that represent the important cases.

• Side effect