* X more docs for C
[mascara-docs.git] / C / the.ansi.c.programming.language / c.programming.notes / sx5.html
blob8f4a381bec779e5ce2f5f655046dad131a5e6c5b
1 <!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
2 <!-- This collection of hypertext pages is Copyright 1995-7 by Steve Summit. -->
3 <!-- This material may be freely redistributed and used -->
4 <!-- but may not be republished or sold without permission. -->
5 <html>
6 <head>
7 <link rev="owner" href="mailto:scs@eskimo.com">
8 <link rev="made" href="mailto:scs@eskimo.com">
9 <title>Chapter 5: Functions and Program Structure</title>
10 <link href="sx4d.html" rev=precedes>
11 <link href="sx5a.html" rel=precedes>
12 <link href="top.html" rev=subdocument>
13 </head>
14 <body>
15 <H1>Chapter 5: Functions and Program Structure</H1>
17 <p>[This chapter corresponds to K&amp;R chapter 4.]
18 </p><p>A function is a ``black box'' that we've locked
19 part of our program into.
20 The idea behind a function is that it <dfn>compartmentalizes</dfn>
21 part of the program,
22 and in particular,
23 that the code within the function has some useful properties:
24 <OL><li>It performs some well-defined task,
25 which will be useful to other parts of the program.
26 <li>It might be useful to other programs as well;
27 that is,
28 we might be able to reuse it
29 (and without having to rewrite it).
30 <li>The rest of the program doesn't have to know the details of how
31 the function is implemented.
32 This can make the rest of the program easier to think about.
33 <li>The function performs its task <em>well</em>.
34 It may be written to do a little more than is required by the
35 first program that calls it,
36 with the anticipation that the calling program
37 (or some other program)
38 may later need the extra functionality or improved performance.
39 (It's important that a finished function do its job well,
40 otherwise there might be a reluctance to call it,
41 and it therefore might not achieve the goal of reusability.)
42 <li>By placing the code to perform the useful task into a function,
43 and simply calling the function in the other parts of the
44 program where the task must be performed,
45 the rest of the program becomes clearer:
46 rather than having some large, complicated,
47 difficult-to-understand piece of code repeated wherever the
48 task is being performed,
49 we have a single simple function call,
50 and the name of the function reminds us which task is being
51 performed.
52 <li>Since the rest of the program doesn't have to know the details of how
53 the function is implemented,
54 the rest of the program doesn't care if the function is
55 reimplemented later,
56 in some different way
57 (as long as it continues to perform its same task, of course!).
58 This means that one part of the program can be rewritten,
59 to improve performance or add a new feature
60 (or simply to fix a bug),
61 without having to rewrite the rest of the program.
62 </OL></p><p>Functions are probably the most important weapon
63 in our battle against software complexity.
64 You'll want to learn when it's appropriate
65 to break processing out into functions
66 (and also when it's not),
67 and <em>how</em> to set up function interfaces
68 to best achieve the qualities mentioned above:
69 reuseability,
70 information hiding,
71 clarity,
72 and
73 maintainability.
74 </p><p><a href="sx5a.html" rel=subdocument>5.1 Function Basics</a></p>
75 <p><a href="sx5b.html" rel=subdocument>5.2 Function Prototypes</a></p>
76 <p><a href="sx5c.html" rel=subdocument>5.3 Function Philosophy</a></p>
77 <p><a href="sx5d.html" rel=subdocument>5.4 Separate Compilation--Logistics</a></p>
78 <hr>
79 <p>
80 Read sequentially:
81 <a href="sx4d.html" rev=precedes>prev</a>
82 <a href="sx5a.html" rel=precedes>next</a>
83 <a href="top.html" rev=subdocument>up</a>
84 <a href="top.html">top</a>
85 </p>
86 <p>
87 This page by <a href="http://www.eskimo.com/~scs/">Steve Summit</a>
88 // <a href="copyright.html">Copyright</a> 1995-1997
89 // <a href="mailto:scs@eskimo.com">mail feedback</a>
90 </p>
91 </body>
92 </html>