| blob | d339d7c333313e5457422122f4e607cb99c49eac |
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>
13 </head>
14 <body>
17 <p>We'll have more to say later about program structure,
18 but for now let's observe a few basics.
19 A program consists of one or more functions;
20 it may also contain global variables.
21 (Our two example programs so far have contained one function apiece,
22 and no global variables.)
23 At the top of a source file are typically a few boilerplate
25 followed by the definitions (i.e. code) for the functions.
26 (It's also possible to split up the several functions making up
27 a larger program into several source files, as we'll see in a
28 later chapter.)
31 When a sequence of statements should act as one
32 (for example,
33 when they should all serve together as the body of a loop)
34 they can be enclosed in braces
35 (just as for the outer body of the entire function).
38 which is an expression
39 (presumably performing some useful operation)
40 followed
42 by a semicolon.
55 and values.
56 There are other punctuation characters
59 which indicate how the other elements of the program are grouped.
60 Finally, all of the preceding elements can be separated by
62 returns'' between lines.
63 </p><p>The source code for a C program is, for the most part,
64 ``free form.''
65 This means that the compiler does not care how the code is arranged:
66 how it is broken into lines, how the lines are indented,
67 or
68 whether
69 whitespace is
70 used between things like variable names and other punctuation.
72 are an exception;
73 they must appear alone on their own lines, generally unbroken.
76 we'll see other examples later.)
77 You can use whitespace, indentation, and appropriate line breaks
78 to make your programs more readable for yourself and other people
79 (even though the compiler doesn't care).
83 (In fact, the compiler pretends that all it saw was whitespace.)
84 Though comments are ignored by the compiler,
86 (for its author, as well as for others).
88 It's typical to leave a blank line between different parts of
89 the program, to leave a space on either side of operators such
91 loops and other control flow constructs.
92 Typically, we arrange the indentation so that
93 the subsidiary statements controlled by a loop statement
95 in our second example program) are all aligned with each other and
96 placed one tab stop (or some consistent number of spaces) to
97 the right of the controlling statement.
98 This indentation (like all whitespace) is not required by the
99 compiler,
101 (However, it can also be misleading, if used incorrectly or in
102 the face of inadvertent mistakes. The compiler will decide
103 what ``the body of the loop'' is based on its own
104 rules, not the indentation, so if the indentation does not
105 match the compiler's interpretation, confusion is inevitable.)
106 </p><p>To drive home the point that the compiler doesn't care about
107 indentation, line breaks, or other whitespace, here are a few
108 (extreme) examples:
109 The fragments
110 <pre>
112 printf("%d\n", i);
113 </pre>
114 and
115 <pre>
117 </pre>
118 and
119 <pre>
121 </pre>
122 and
123 <pre>
125 printf("%d\n", i);
126 </pre>
127 and
128 <pre>
129 for ( i
130 = 0 ;
132 ; i =
133 i + 1
134 ) printf (
135 "%d\n" , i
136 ) ;
137 </pre>
138 and
139 <pre>
140 for
141 (i=0;
143 i+1)printf
144 ("%d\n", i);
145 </pre>
146 are all treated exactly the same way by the compiler.
147 </p><p>Some programmers argue forever over
148 the best set of
149 ``rules''
150 for indentation and other aspects of
151 programming style,
152 calling to mind the old philosopher's debates about the number
153 of angels that could dance on the head of a pin.
154 Style issues
155 (such as how a program is laid out)
157 but they're not something to be too dogmatic about,
158 and there are
159 also
160 other, deeper style issues besides mere layout
161 and typography.
162 Kernighan and Ritchie take a fairly moderate stance:
163 <blockquote>Although
164 C compilers do not care about how a program looks,
165 proper indentation and spacing are critical
166 in making programs easy
167 for people to read.
168 We recommend writing only one statement per line,
169 and using blanks around operators to clarify grouping.
170 The position of braces is less important,
171 although people hold passionate beliefs.
172 We have chosen one of several popular styles.
173 Pick a style that suits you,
174 then use it consistently.
175 </blockquote></p><p>There is some value in having a reasonably standard style
176 (or a few standard styles)
177 for code layout.
178 Please don't take the above advice to
179 ``pick a style that suits you''
180 as an invitation to invent your own brand-new style.
181 If
182 (perhaps after you've been programming in C for a while)
183 you have specific objections to specific facets of existing styles,
184 you're welcome to modify them,
185 but if you don't have any particular leanings,
186 you're probably best off copying an existing style at first.
188 (If you want to place your own stamp of originality
189 on the programs that you write,
190 there are better avenues for your creativity than inventing a bizarre layout;
191 you might instead try to make the logic easier to follow,
192 or the user interface easier to use,
193 or the code freer of bugs.)
194 </p><hr>
195 <p>
196 Read sequentially:
201 </p>
202 <p>
206 </p>
207 </body>
208 </html>