1 | ##
|
---|
2 | ## Coding conventions in the Samba 3 tree
|
---|
3 | ##
|
---|
4 |
|
---|
5 | ===========
|
---|
6 | Quick Start
|
---|
7 | ===========
|
---|
8 |
|
---|
9 | Coding style guidelines are about reducing the number of unnecessary
|
---|
10 | reformatting patches and making things easier for developers to work together.
|
---|
11 | You don't have to like them or even agree with them, but once put in place
|
---|
12 | we all have to abide by them (or vote to change them). However, coding
|
---|
13 | style should never outweigh coding itself and so the the guidelines
|
---|
14 | described here are hopefully easy enough to follow as they are very
|
---|
15 | common and supported by tools and editors.
|
---|
16 |
|
---|
17 | The basic style, also mentioned in the SAMBA_4_0/prog_guide.txt is the
|
---|
18 | Linux kernel coding style (See Documentation/CodingStyle in the kernel
|
---|
19 | source tree). The closely matches what most Samba developers use already
|
---|
20 | anyways.
|
---|
21 |
|
---|
22 | But to save you the trouble of reading the Linux kernel style guide, here
|
---|
23 | are the highlights.
|
---|
24 |
|
---|
25 |
|
---|
26 | * Maximum Line Width is 80 Characters
|
---|
27 | The reason is not for people with low-res screens but rather sticking
|
---|
28 | to 80 columns prevents you from easily nesting more than one level of
|
---|
29 | if statements or other code blocks. Use source/script/count_80_col.pl
|
---|
30 | to check your changes.
|
---|
31 |
|
---|
32 | * Use 8 Space Tabs to Indent
|
---|
33 | No whitespace filler.
|
---|
34 |
|
---|
35 | * No Trailing Whitespace
|
---|
36 | Use source/script/strip_trail_ws.pl to clean you files before committing.
|
---|
37 |
|
---|
38 | * Follow the K&R guidelines. We won't go throw them all here. You have
|
---|
39 | a copy of "The C Programming Language" anyways right? You can also use
|
---|
40 | the format_indent.sh script found in source/script/ if all else fails.
|
---|
41 |
|
---|
42 |
|
---|
43 |
|
---|
44 | ============
|
---|
45 | Editor Hints
|
---|
46 | ============
|
---|
47 |
|
---|
48 | Emacs
|
---|
49 | -----
|
---|
50 | Add the follow to your $HOME/.emacs file:
|
---|
51 |
|
---|
52 | (add-hook 'c-mode-hook
|
---|
53 | (lambda ()
|
---|
54 | (c-set-style "linux")
|
---|
55 | (c-toggle-auto-state)))
|
---|
56 |
|
---|
57 |
|
---|
58 | Vi
|
---|
59 | --
|
---|
60 | (Thanks to SATOH Fumiyasu <fumiyas@osstech.jp> for these hints):
|
---|
61 |
|
---|
62 | For the basic vi editor including with all variants of *nix, add the
|
---|
63 | following to $HOME/.exrc:
|
---|
64 |
|
---|
65 | set tabstop=8
|
---|
66 | set shiftwidth=8
|
---|
67 |
|
---|
68 | For Vim, the following settings in $HOME/.vimrc will also deal with
|
---|
69 | displaying trailing whitespace:
|
---|
70 |
|
---|
71 | if has("syntax") && (&t_Co > 2 || has("gui_running"))
|
---|
72 | syntax on
|
---|
73 | function! ActivateInvisibleCharIndicator()
|
---|
74 | syntax match TrailingSpace "[ \t]\+$" display containedin=ALL
|
---|
75 | highlight TrailingSpace ctermbg=Red
|
---|
76 | endf
|
---|
77 | autocmd BufNewFile,BufRead * call ActivateInvisibleCharIndicator()
|
---|
78 | endif
|
---|
79 | " Show tabs, trailing whitespace, and continued lines visually
|
---|
80 | set list listchars=tab:»·,trail:·,extends:âŠ
|
---|
81 |
|
---|
82 | " highlight overly long lines same as TODOs.
|
---|
83 | set textwidth=80
|
---|
84 | autocmd BufNewFile,BufRead *.c,*.h exec 'match Todo /\%>' . &textwidth . 'v.\+/'
|
---|
85 |
|
---|
86 |
|
---|
87 | =========================
|
---|
88 | FAQ & Statement Reference
|
---|
89 | =========================
|
---|
90 |
|
---|
91 | Comments
|
---|
92 | --------
|
---|
93 |
|
---|
94 | Comments should always use the standard C syntax. I.e. /* ... */. C++
|
---|
95 | style comments are not currently allowed.
|
---|
96 |
|
---|
97 |
|
---|
98 | Indention & Whitespace & 80 columns
|
---|
99 | -----------------------------------
|
---|
100 |
|
---|
101 | To avoid confusion, indentations are to be 8 character with tab (not
|
---|
102 | 8 ' ' characters. When wrapping parameters for function calls,
|
---|
103 | alignment parameter list with the first parameter on the previous line.
|
---|
104 | Use tabs to get as close as possible and then fill in the final 7
|
---|
105 | characters or less with whitespace. For example,
|
---|
106 |
|
---|
107 | var1 = foo(arg1, arg2,
|
---|
108 | arg3);
|
---|
109 |
|
---|
110 | The previous example is intended to illustrate alignment of function
|
---|
111 | parameters across lines and not as encourage for gratuitous line
|
---|
112 | splitting. Never split a line before columns 70 - 79 unless you
|
---|
113 | have a really good reason. Be smart about formatting.
|
---|
114 |
|
---|
115 |
|
---|
116 | If, switch, & Code blocks
|
---|
117 | -------------------------
|
---|
118 |
|
---|
119 | Always follow an 'if' keyword with a space but don't include additional
|
---|
120 | spaces following or preceding the parentheses in the conditional.
|
---|
121 | This is good:
|
---|
122 |
|
---|
123 | if (x == 1)
|
---|
124 |
|
---|
125 | This is bad:
|
---|
126 |
|
---|
127 | if ( x == 1 )
|
---|
128 |
|
---|
129 | Yes we have a lot of code that uses the second form and we are trying
|
---|
130 | to clean it up without being overly intrusive.
|
---|
131 |
|
---|
132 | Note that this is a rule about parentheses following keywords and not
|
---|
133 | functions. Don't insert a space between the name and left parentheses when
|
---|
134 | invoking functions.
|
---|
135 |
|
---|
136 | Braces for code blocks used by for, if, switch, while, do..while, etc...
|
---|
137 | should begin on the same line as the statement keyword and end on a line
|
---|
138 | of their own. NOTE: Functions are different and the beginning left brace
|
---|
139 | should begin on a line of its own.
|
---|
140 |
|
---|
141 | If the beginning statement has to be broken across lines due to length,
|
---|
142 | the beginning brace should be on a line of its own.
|
---|
143 |
|
---|
144 | The exception to the ending rule is when the closing brace is followed by
|
---|
145 | another language keyword such as else or the closing while in a do..while
|
---|
146 | loop.
|
---|
147 |
|
---|
148 | Good examples:
|
---|
149 |
|
---|
150 | if (x == 1) {
|
---|
151 | printf("good\n");
|
---|
152 | }
|
---|
153 |
|
---|
154 | for (x=1;
|
---|
155 | x<10;
|
---|
156 | x++)
|
---|
157 | {
|
---|
158 | print("%d\n", x);
|
---|
159 | }
|
---|
160 |
|
---|
161 | do {
|
---|
162 | printf("also good\n");
|
---|
163 | } while (1);
|
---|
164 |
|
---|
165 | Bad examples:
|
---|
166 |
|
---|
167 | while (1)
|
---|
168 | {
|
---|
169 | print("I'm in a loop!\n"); }
|
---|
170 |
|
---|
171 |
|
---|
172 | Goto
|
---|
173 | ----
|
---|
174 |
|
---|
175 | While many people have been academically taught that goto's are fundamentally
|
---|
176 | evil, then can greatly enhance readability and reduce memory leaks when used
|
---|
177 | as the single exit point from a function. But in no Samba world what so ever
|
---|
178 | is a goto outside of a function or block of code a good idea.
|
---|
179 |
|
---|
180 | Good Examples:
|
---|
181 |
|
---|
182 | int function foo(int y)
|
---|
183 | {
|
---|
184 | int *z = NULL;
|
---|
185 | int ret = 0;
|
---|
186 |
|
---|
187 | if ( y < 10 ) {
|
---|
188 | z = malloc(sizeof(int)*y);
|
---|
189 | if (!z) {
|
---|
190 | ret = 1;
|
---|
191 | goto done;
|
---|
192 | }
|
---|
193 | }
|
---|
194 |
|
---|
195 | print("Allocated %d elements.\n", y);
|
---|
196 |
|
---|
197 | done:
|
---|
198 | if (z)
|
---|
199 | free(z);
|
---|
200 |
|
---|
201 | return ret;
|
---|
202 | }
|
---|
203 |
|
---|
204 |
|
---|
205 | Checking Pointer Values
|
---|
206 | -----------------------
|
---|
207 |
|
---|
208 | When invoking functions that return pointer values, either of the following
|
---|
209 | are acceptable. Use you best judgement and choose the more readable option.
|
---|
210 | Remember that many other people will review it.
|
---|
211 |
|
---|
212 | if ((x = malloc(sizeof(short)*10)) == NULL ) {
|
---|
213 | fprintf(stderr, "Unable to alloc memory!\n");
|
---|
214 | }
|
---|
215 |
|
---|
216 | or
|
---|
217 |
|
---|
218 | x = malloc(sizeof(short)*10);
|
---|
219 | if (!x) {
|
---|
220 | fprintf(stderr, "Unable to alloc memory!\n");
|
---|
221 | }
|
---|
222 |
|
---|
223 |
|
---|
224 | Primitive Data Types
|
---|
225 | --------------------
|
---|
226 |
|
---|
227 | Samba has large amounts of historical code which makes use of data types
|
---|
228 | commonly supported by the C99 standard. However, at the time such types
|
---|
229 | as boolean and exact width integers did not exist and Samba developers
|
---|
230 | were forced to provide their own. Now that these types are guaranteed to
|
---|
231 | be available either as part of the compiler C99 support or from lib/replace/,
|
---|
232 | new code should adhere to the following conventions:
|
---|
233 |
|
---|
234 | * Booleans are of type "bool" (not BOOL)
|
---|
235 | * Boolean values are "true" and "false" (not True or False)
|
---|
236 | * Exact width integers are of type [u]int[8|16|32|64]_t
|
---|