| blob | 0c16c755c0a0f04e923a212ac98580111ffaa811 |
2 <!-- This collection of hypertext pages is Copyright 1995, 1996 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>
13 </head>
14 <body>
17 <p>What makes a good
18 function?
19 The most important aspect of a good ``building block''
20 is that have a single, well-defined task to perform.
22 When you find that a program is hard to manage,
23 it's often because it has not been designed
24 and broken up into functions cleanly.
25 Two obvious reasons for moving code down into a function are
26 because:
28 It appeared in the main program several times,
29 such that by making it a function,
30 it can be written just once,
31 and the several places where it used to appear
32 can be
33 replaced with calls to the new function.
35 The main program was getting too big,
36 so it could be made (presumably) smaller and more manageable by
37 lopping part of it off and making it a function.
38 <p>These two reasons are important,
39 and they represent significant benefits of well-chosen functions,
40 but they are not sufficient to automatically identify
41 a good function.
42 As we've been suggesting,
43 a
44 good function has at least these two additional attributes:
46 It does just one well-defined task, and does it well.
48 Its interface to the rest of the program is clean and narrow.
50 two things
51 we said above.
52 Attribute 4 says that you shouldn't have to keep track of too many things
53 when calling a function.
54 If you know what a function is supposed to do,
55 and if its task is simple and well-defined,
56 there should be just a few pieces of information
57 you have to give it to act upon,
58 and one or just a few pieces of information
59 which
60 it returns to you when it's done.
61 If you find yourself having to pass lots and lots of
62 information to a function,
63 or remember details of its internal implementation to make sure
64 that it will work properly this time,
65 it's often a sign that the function is not sufficiently well-defined.
66 (A poorly-defined function
67 may be an arbitrary chunk of code that was ripped out of a
68 main program
69 that was getting too big,
70 such that it essentially has to have access to
71 all of that main function's local variables.)
72 </p><p>The whole point of breaking a program up into functions
73 is so that you don't have to think about the entire program at once;
74 ideally, you can think about just one function at a time.
75 We say that a good function is a ``black box,''
76 which is supposed to suggest
77 that the ``container'' it's in is
78 opaque--callers can't see inside it
79 (and the function inside
80 can't see out).
81 When you call a function,
82 you only have to know what it does,
83 not how it does it.
85 you only have to know what it's supposed to do,
86 and you don't have to know why or under what circumstances
87 its caller will be calling it.
88 (When designing a function,
89 we should perhaps think about the callers just enough to
90 ensure that the function we're designing will be easy to call,
91 and that
92 we aren't accidentally setting things up
93 so that callers will have to think about any internal details.)
94 </p><p>Some functions may be hard to write
95 (if they have a hard job to do,
96 or if it's hard to make them do it truly well),
97 but that difficulty should be compartmentalized along with the
98 function itself.
99 Once you've written a ``hard'' function,
100 you should be able to sit back and relax
101 and watch it do that hard work on call from the rest of your program.
102 It should be pleasant to notice
103 (in the ideal case)
104 how much easier the rest of the program is to write,
105 now that the hard work can be deferred to this
106 workhorse
108 function.
109 </p><p>(In fact,
110 if a difficult-to-write function's interface is well-defined,
111 you may be able to get away with writing a quick-and-dirty
112 version of the function first,
113 so that you can begin testing the rest of the program,
114 and then go back later and rewrite the function to do the hard parts.
115 As long as the function's original interface anticipated the hard parts,
116 you won't have to rewrite the rest of the program when you fix the function.)
117 </p><p>What I've been trying to say in the preceding few paragraphs
118 is that functions are important
119 for
120 far
121 more important reasons
122 than just saving typing.
123 Sometimes,
124 we'll write a function which we only call once,
125 just because breaking it out into a function
126 makes things clearer and easier.
127 </p><p>If you find that difficulties pervade a program,
128 that the hard parts can't be buried inside black-box functions
129 and then forgotten about;
130 if you find that there are hard parts which involve complicated
131 interactions among multiple functions,
132 then the program probably needs redesigning.
133 </p><p>For the purposes of explanation,
134 we've been seeming to talk so far only about ``main programs''
135 and the functions they call and the rationale behind moving
136 some piece of code down out of a ``main program'' into a function.
137 But in reality,
138 there's obviously no need to restrict ourselves to a two-tier
139 scheme.
140 Any function we find ourself writing
141 will often be appropriately written
142 in terms of sub-functions, sub-sub-functions, etc.
143 (Furthermore,
145 is itself just a function.)
146 </p><hr>
147 <p>
148 Read sequentially:
153 </p>
154 <p>
158 </p>
159 </body>
160 </html>