| [206] | 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
 | 
|---|