Chapter 5: Functions and Program Structure
[This chapter corresponds to K&R chapter 4.]
A function is a ``black box'' that we've locked
part of our program into.
The idea behind a function is that it compartmentalizes
part of the program,
and in particular,
that the code within the function has some useful properties:
- It performs some well-defined task,
which will be useful to other parts of the program.
- It might be useful to other programs as well;
we might be able to reuse it
(and without having to rewrite it).
- The rest of the program doesn't have to know the details of how
the function is implemented.
This can make the rest of the program easier to think about.
- The function performs its task well.
It may be written to do a little more than is required by the
first program that calls it,
with the anticipation that the calling program
(or some other program)
may later need the extra functionality or improved performance.
(It's important that a finished function do its job well,
otherwise there might be a reluctance to call it,
and it therefore might not achieve the goal of reusability.)
- By placing the code to perform the useful task into a function,
and simply calling the function in the other parts of the
program where the task must be performed,
the rest of the program becomes clearer:
rather than having some large, complicated,
difficult-to-understand piece of code repeated wherever the
task is being performed,
we have a single simple function call,
and the name of the function reminds us which task is being
- Since the rest of the program doesn't have to know the details of how
the function is implemented,
the rest of the program doesn't care if the function is
in some different way
(as long as it continues to perform its same task, of course!).
This means that one part of the program can be rewritten,
to improve performance or add a new feature
(or simply to fix a bug),
without having to rewrite the rest of the program.
Functions are probably the most important weapon
in our battle against software complexity.
You'll want to learn when it's appropriate
to break processing out into functions
(and also when it's not),
and how to set up function interfaces
to best achieve the qualities mentioned above:
5.1 Function Basics
5.2 Function Prototypes
5.3 Function Philosophy
5.4 Separate Compilation--Logistics
This page by Steve Summit
// Copyright 1995-1997
// mail feedback