Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 1 | Busybox Style Guide |
| 2 | =================== |
| 3 | |
| 4 | This document describes the coding style conventions used in Busybox. If you |
| 5 | add a new file to Busybox or are editing an existing file, please format your |
| 6 | code according to this style. If you are the maintainer of a file that does |
| 7 | not follow these guidelines, please -- at your own convenience -- modify the |
| 8 | file(s) you maintain to bring them into conformance with this style guide. |
| 9 | Please note that this is a low priority task. |
| 10 | |
| 11 | To help you format the whitespace of your programs, an ".indent.pro" file is |
| 12 | included in the main Busybox source directory that contains option flags to |
| 13 | format code as per this style guide. This way you can run GNU indent on your |
| 14 | files by typing 'indent myfile.c myfile.h' and it will magically apply all the |
| 15 | right formatting rules to your file. Please _do_not_ run this on all the files |
| 16 | in the directory, just your own. |
| 17 | |
Mark Whitley | 2368a38 | 2000-08-22 00:20:21 +0000 | [diff] [blame] | 18 | |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 19 | |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 20 | Declaration Order |
| 21 | ----------------- |
| 22 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 23 | Here is the preferred order in which code should be laid out in a file: |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 24 | |
Mark Whitley | 9028e2c | 2000-11-17 21:28:39 +0000 | [diff] [blame] | 25 | - commented program name and one-line description |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 26 | - commented author name and email address(es) |
| 27 | - commented GPL boilerplate |
Mark Whitley | 9028e2c | 2000-11-17 21:28:39 +0000 | [diff] [blame] | 28 | - commented longer description / notes for the program (if needed) |
Mark Whitley | 9ead689 | 2001-03-03 00:44:55 +0000 | [diff] [blame] | 29 | - #includes of .h files with angle brackets (<>) around them |
| 30 | - #includes of .h files with quotes ("") around them |
| 31 | - #defines (if any, note the section below titled "Avoid the Preprocessor") |
Mark Whitley | 9028e2c | 2000-11-17 21:28:39 +0000 | [diff] [blame] | 32 | - const and global variables |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 33 | - function declarations (if necessary) |
| 34 | - function implementations |
| 35 | |
Mark Whitley | 2368a38 | 2000-08-22 00:20:21 +0000 | [diff] [blame] | 36 | |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 37 | |
| 38 | Whitespace and Formatting |
| 39 | ------------------------- |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 40 | |
Mark Whitley | 2368a38 | 2000-08-22 00:20:21 +0000 | [diff] [blame] | 41 | This is everybody's favorite flame topic so let's get it out of the way right |
| 42 | up front. |
| 43 | |
| 44 | |
Mark Whitley | 9028e2c | 2000-11-17 21:28:39 +0000 | [diff] [blame] | 45 | Tabs vs. Spaces in Line Indentation |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 46 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
Mark Whitley | 2368a38 | 2000-08-22 00:20:21 +0000 | [diff] [blame] | 47 | |
| 48 | The preference in Busybox is to indent lines with tabs. Do not indent lines |
| 49 | with spaces and do not indents lines using a mixture of tabs and spaces. (The |
| 50 | indentation style in the Apache and Postfix source does this sort of thing: |
| 51 | \s\s\s\sif (expr) {\n\tstmt; --ick.) The only exception to this rule is |
| 52 | multi-line comments that use an asterisk at the beginning of each line, i.e.: |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 53 | |
Mike Frysinger | 434ccd9 | 2006-07-05 22:19:21 +0000 | [diff] [blame] | 54 | \t/* |
| 55 | \t * This is a block comment. |
| 56 | \t * Note that it has multiple lines |
| 57 | \t * and that the beginning of each line has a tab plus a space |
| 58 | \t * except for the opening '/*' line where the slash |
| 59 | \t * is used instead of a space. |
| 60 | \t */ |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 61 | |
| 62 | Furthermore, The preference is that tabs be set to display at four spaces |
| 63 | wide, but the beauty of using only tabs (and not spaces) at the beginning of |
Mark Whitley | 9028e2c | 2000-11-17 21:28:39 +0000 | [diff] [blame] | 64 | lines is that you can set your editor to display tabs at *whatever* number of |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 65 | spaces is desired and the code will still look fine. |
| 66 | |
| 67 | |
Mark Whitley | 2368a38 | 2000-08-22 00:20:21 +0000 | [diff] [blame] | 68 | Operator Spacing |
| 69 | ~~~~~~~~~~~~~~~~ |
| 70 | |
| 71 | Put spaces between terms and operators. Example: |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 72 | |
| 73 | Don't do this: |
| 74 | |
| 75 | for(i=0;i<num_items;i++){ |
| 76 | |
| 77 | Do this instead: |
| 78 | |
| 79 | for (i = 0; i < num_items; i++) { |
| 80 | |
| 81 | While it extends the line a bit longer, the spaced version is more |
| 82 | readable. An allowable exception to this rule is the situation where |
| 83 | excluding the spacing makes it more obvious that we are dealing with a |
Mark Whitley | 9028e2c | 2000-11-17 21:28:39 +0000 | [diff] [blame] | 84 | single term (even if it is a compound term) such as: |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 85 | |
| 86 | if (str[idx] == '/' && str[idx-1] != '\\') |
| 87 | |
| 88 | or |
| 89 | |
| 90 | if ((argc-1) - (optind+1) > 0) |
| 91 | |
| 92 | |
Mark Whitley | 2368a38 | 2000-08-22 00:20:21 +0000 | [diff] [blame] | 93 | Bracket Spacing |
| 94 | ~~~~~~~~~~~~~~~ |
| 95 | |
| 96 | If an opening bracket starts a function, it should be on the |
Mark Whitley | 9028e2c | 2000-11-17 21:28:39 +0000 | [diff] [blame] | 97 | next line with no spacing before it. However, if a bracket follows an opening |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 98 | control block, it should be on the same line with a single space (not a tab) |
Mark Whitley | 9028e2c | 2000-11-17 21:28:39 +0000 | [diff] [blame] | 99 | between it and the opening control block statement. Examples: |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 100 | |
| 101 | Don't do this: |
| 102 | |
Mark Whitley | 9028e2c | 2000-11-17 21:28:39 +0000 | [diff] [blame] | 103 | while (!done) |
| 104 | { |
| 105 | |
| 106 | do |
| 107 | { |
| 108 | |
| 109 | Don't do this either: |
| 110 | |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 111 | while (!done){ |
Mark Whitley | 925edb8 | 2001-02-03 00:20:14 +0000 | [diff] [blame] | 112 | |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 113 | do{ |
| 114 | |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 115 | And for heaven's sake, don't do this: |
| 116 | |
| 117 | while (!done) |
| 118 | { |
Mark Whitley | 925edb8 | 2001-02-03 00:20:14 +0000 | [diff] [blame] | 119 | |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 120 | do |
| 121 | { |
| 122 | |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 123 | Do this instead: |
| 124 | |
| 125 | while (!done) { |
Mark Whitley | 925edb8 | 2001-02-03 00:20:14 +0000 | [diff] [blame] | 126 | |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 127 | do { |
| 128 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 129 | If you have long logic statements that need to be wrapped, then uncuddling |
| 130 | the bracket to improve readability is allowed. Generally, this style makes |
| 131 | it easier for reader to notice that 2nd and following lines are still |
| 132 | inside 'if': |
Mike Frysinger | 0612b5f | 2006-02-24 01:18:24 +0000 | [diff] [blame] | 133 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 134 | if (some_really_long_checks && some_other_really_long_checks |
| 135 | && some_more_really_long_checks |
| 136 | && even_more_of_long_checks |
| 137 | ) { |
Mike Frysinger | 0612b5f | 2006-02-24 01:18:24 +0000 | [diff] [blame] | 138 | do_foo_now; |
Mark Whitley | 2368a38 | 2000-08-22 00:20:21 +0000 | [diff] [blame] | 139 | |
Mark Whitley | 925edb8 | 2001-02-03 00:20:14 +0000 | [diff] [blame] | 140 | Spacing around Parentheses |
| 141 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
Mark Whitley | 2368a38 | 2000-08-22 00:20:21 +0000 | [diff] [blame] | 142 | |
Mark Whitley | 7ddaf7c | 2001-03-14 21:04:53 +0000 | [diff] [blame] | 143 | Put a space between C keywords and left parens, but not between function names |
| 144 | and the left paren that starts it's parameter list (whether it is being |
| 145 | declared or called). Examples: |
Mark Whitley | 2368a38 | 2000-08-22 00:20:21 +0000 | [diff] [blame] | 146 | |
| 147 | Don't do this: |
| 148 | |
| 149 | while(foo) { |
| 150 | for(i = 0; i < n; i++) { |
| 151 | |
| 152 | Do this instead: |
| 153 | |
| 154 | while (foo) { |
| 155 | for (i = 0; i < n; i++) { |
| 156 | |
Mark Whitley | 9028e2c | 2000-11-17 21:28:39 +0000 | [diff] [blame] | 157 | But do functions like this: |
Mark Whitley | 2368a38 | 2000-08-22 00:20:21 +0000 | [diff] [blame] | 158 | |
| 159 | static int my_func(int foo, char bar) |
| 160 | ... |
| 161 | baz = my_func(1, 2); |
| 162 | |
Mark Whitley | 925edb8 | 2001-02-03 00:20:14 +0000 | [diff] [blame] | 163 | Also, don't put a space between the left paren and the first term, nor between |
| 164 | the last arg and the right paren. |
| 165 | |
| 166 | Don't do this: |
| 167 | |
| 168 | if ( x < 1 ) |
| 169 | strcmp( thisstr, thatstr ) |
| 170 | |
| 171 | Do this instead: |
| 172 | |
| 173 | if (x < 1) |
| 174 | strcmp(thisstr, thatstr) |
| 175 | |
Mark Whitley | 2368a38 | 2000-08-22 00:20:21 +0000 | [diff] [blame] | 176 | |
| 177 | Cuddled Elses |
| 178 | ~~~~~~~~~~~~~ |
| 179 | |
Mark Whitley | 9028e2c | 2000-11-17 21:28:39 +0000 | [diff] [blame] | 180 | Also, please "cuddle" your else statements by putting the else keyword on the |
| 181 | same line after the right bracket that closes an 'if' statement. |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 182 | |
| 183 | Don't do this: |
| 184 | |
| 185 | if (foo) { |
| 186 | stmt; |
| 187 | } |
| 188 | else { |
| 189 | stmt; |
| 190 | } |
| 191 | |
| 192 | Do this instead: |
| 193 | |
| 194 | if (foo) { |
| 195 | stmt; |
| 196 | } else { |
| 197 | stmt; |
| 198 | } |
| 199 | |
Mark Whitley | 9028e2c | 2000-11-17 21:28:39 +0000 | [diff] [blame] | 200 | The exception to this rule is if you want to include a comment before the else |
| 201 | block. Example: |
| 202 | |
| 203 | if (foo) { |
| 204 | stmts... |
| 205 | } |
| 206 | /* otherwise, we're just kidding ourselves, so re-frob the input */ |
| 207 | else { |
| 208 | other_stmts... |
| 209 | } |
| 210 | |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 211 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 212 | Labels |
| 213 | ~~~~~~ |
| 214 | |
| 215 | Labels should start at the beginning of the line, not indented to the block |
| 216 | level (because they do not "belong" to block scope, only to whole function). |
| 217 | |
| 218 | if (foo) { |
| 219 | stmt; |
| 220 | label: |
| 221 | stmt2; |
| 222 | stmt; |
| 223 | } |
| 224 | |
| 225 | (Putting label at position 1 prevents diff -p from confusing label for function |
| 226 | name, but it's not a policy of busybox project to enforce such a minor detail). |
| 227 | |
| 228 | |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 229 | |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 230 | Variable and Function Names |
| 231 | --------------------------- |
| 232 | |
| 233 | Use the K&R style with names in all lower-case and underscores occasionally |
Mark Whitley | 9028e2c | 2000-11-17 21:28:39 +0000 | [diff] [blame] | 234 | used to separate words (e.g., "variable_name" and "numchars" are both |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 235 | acceptable). Using underscores makes variable and function names more readable |
| 236 | because it looks like whitespace; using lower-case is easy on the eyes. |
| 237 | |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 238 | Frowned upon: |
| 239 | |
| 240 | hitList |
| 241 | TotalChars |
Mark Whitley | a5b55ca | 2001-01-24 00:18:13 +0000 | [diff] [blame] | 242 | szFileName |
| 243 | pf_Nfol_TriState |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 244 | |
| 245 | Preferred: |
| 246 | |
| 247 | hit_list |
| 248 | total_chars |
| 249 | file_name |
Mark Whitley | a5b55ca | 2001-01-24 00:18:13 +0000 | [diff] [blame] | 250 | sensible_name |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 251 | |
Mark Whitley | a5b55ca | 2001-01-24 00:18:13 +0000 | [diff] [blame] | 252 | Exceptions: |
| 253 | |
Mark Whitley | 7ddaf7c | 2001-03-14 21:04:53 +0000 | [diff] [blame] | 254 | - Enums, macros, and constant variables are occasionally written in all |
Denys Vlasenko | 5370bfb | 2009-09-06 02:58:59 +0200 | [diff] [blame^] | 255 | upper-case with words optionally separated by underscores (i.e. FIFO_TYPE, |
Mark Whitley | 7ddaf7c | 2001-03-14 21:04:53 +0000 | [diff] [blame] | 256 | ISBLKDEV()). |
Mark Whitley | a5b55ca | 2001-01-24 00:18:13 +0000 | [diff] [blame] | 257 | |
| 258 | - Nobody is going to get mad at you for using 'pvar' as the name of a |
| 259 | variable that is a pointer to 'var'. |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 260 | |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 261 | |
Mark Whitley | 7ddaf7c | 2001-03-14 21:04:53 +0000 | [diff] [blame] | 262 | Converting to K&R |
| 263 | ~~~~~~~~~~~~~~~~~ |
| 264 | |
| 265 | The Busybox codebase is very much a mixture of code gathered from a variety of |
| 266 | sources. This explains why the current codebase contains such a hodge-podge of |
| 267 | different naming styles (Java, Pascal, K&R, just-plain-weird, etc.). The K&R |
| 268 | guideline explained above should therefore be used on new files that are added |
| 269 | to the repository. Furthermore, the maintainer of an existing file that uses |
| 270 | alternate naming conventions should, at his own convenience, convert those |
| 271 | names over to K&R style. Converting variable names is a very low priority |
| 272 | task. |
| 273 | |
| 274 | If you want to do a search-and-replace of a single variable name in different |
| 275 | files, you can do the following in the busybox directory: |
Mark Whitley | a5b55ca | 2001-01-24 00:18:13 +0000 | [diff] [blame] | 276 | |
| 277 | $ perl -pi -e 's/\bOldVar\b/new_var/g' *.[ch] |
| 278 | |
Mark Whitley | 7ddaf7c | 2001-03-14 21:04:53 +0000 | [diff] [blame] | 279 | If you want to convert all the non-K&R vars in your file all at once, follow |
| 280 | these steps: |
| 281 | |
Eric Andersen | bdfd0d7 | 2001-10-24 05:00:29 +0000 | [diff] [blame] | 282 | - In the busybox directory type 'examples/mk2knr.pl files-to-convert'. This |
Mark Whitley | 7ddaf7c | 2001-03-14 21:04:53 +0000 | [diff] [blame] | 283 | does not do the actual conversion, rather, it generates a script called |
| 284 | 'convertme.pl' that shows what will be converted, giving you a chance to |
| 285 | review the changes beforehand. |
| 286 | |
| 287 | - Review the 'convertme.pl' script that gets generated in the busybox |
| 288 | directory and remove / edit any of the substitutions in there. Please |
| 289 | especially check for false positives (strings that should not be |
| 290 | converted). |
| 291 | |
| 292 | - Type './convertme.pl same-files-as-before' to perform the actual |
| 293 | conversion. |
| 294 | |
| 295 | - Compile and see if everything still works. |
Eric Andersen | c7bda1c | 2004-03-15 08:29:22 +0000 | [diff] [blame] | 296 | |
Mark Whitley | 7ddaf7c | 2001-03-14 21:04:53 +0000 | [diff] [blame] | 297 | Please be aware of changes that have cascading effects into other files. For |
| 298 | example, if you're changing the name of something in, say utility.c, you |
Eric Andersen | bdfd0d7 | 2001-10-24 05:00:29 +0000 | [diff] [blame] | 299 | should probably run 'examples/mk2knr.pl utility.c' at first, but when you run |
Mark Whitley | 7ddaf7c | 2001-03-14 21:04:53 +0000 | [diff] [blame] | 300 | the 'convertme.pl' script you should run it on _all_ files like so: |
| 301 | './convertme.pl *.[ch]'. |
| 302 | |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 303 | |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 304 | |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 305 | Avoid The Preprocessor |
| 306 | ---------------------- |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 307 | |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 308 | At best, the preprocessor is a necessary evil, helping us account for platform |
| 309 | and architecture differences. Using the preprocessor unnecessarily is just |
| 310 | plain evil. |
Mark Whitley | 2368a38 | 2000-08-22 00:20:21 +0000 | [diff] [blame] | 311 | |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 312 | |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 313 | The Folly of #define |
| 314 | ~~~~~~~~~~~~~~~~~~~~ |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 315 | |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 316 | Use 'const <type> var' for declaring constants. |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 317 | |
| 318 | Don't do this: |
| 319 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 320 | #define CONST 80 |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 321 | |
| 322 | Do this instead, when the variable is in a header file and will be used in |
Eric Andersen | c7bda1c | 2004-03-15 08:29:22 +0000 | [diff] [blame] | 323 | several source files: |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 324 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 325 | enum { CONST = 80 }; |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 326 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 327 | Although enum may look ugly to some people, it is better for code size. |
| 328 | With "const int" compiler may fail to optimize it out and will reserve |
| 329 | a real storage in rodata for it! (Hopefully, newer gcc will get better |
| 330 | at it...). With "define", you have slight risk of polluting namespace |
| 331 | (#define doesn't allow you to redefine the name in the inner scopes), |
| 332 | and complex "define" are evaluated each time they uesd, not once |
| 333 | at declarations like enums. Also, the preprocessor does _no_ type checking |
| 334 | whatsoever, making it much more error prone. |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 335 | |
| 336 | |
| 337 | The Folly of Macros |
| 338 | ~~~~~~~~~~~~~~~~~~~ |
| 339 | |
| 340 | Use 'static inline' instead of a macro. |
| 341 | |
| 342 | Don't do this: |
| 343 | |
| 344 | #define mini_func(param1, param2) (param1 << param2) |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 345 | |
| 346 | Do this instead: |
| 347 | |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 348 | static inline int mini_func(int param1, param2) |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 349 | { |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 350 | return (param1 << param2); |
| 351 | } |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 352 | |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 353 | Static inline functions are greatly preferred over macros. They provide type |
Mark Whitley | 7ddaf7c | 2001-03-14 21:04:53 +0000 | [diff] [blame] | 354 | safety, have no length limitations, no formatting limitations, have an actual |
| 355 | return value, and under gcc they are as cheap as macros. Besides, really long |
| 356 | macros with backslashes at the end of each line are ugly as sin. |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 357 | |
| 358 | |
| 359 | The Folly of #ifdef |
| 360 | ~~~~~~~~~~~~~~~~~~~ |
| 361 | |
| 362 | Code cluttered with ifdefs is difficult to read and maintain. Don't do it. |
Mark Whitley | 7ddaf7c | 2001-03-14 21:04:53 +0000 | [diff] [blame] | 363 | Instead, put your ifdefs at the top of your .c file (or in a header), and |
| 364 | conditionally define 'static inline' functions, (or *maybe* macros), which are |
Eric Andersen | c7bda1c | 2004-03-15 08:29:22 +0000 | [diff] [blame] | 365 | used in the code. |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 366 | |
| 367 | Don't do this: |
| 368 | |
| 369 | ret = my_func(bar, baz); |
| 370 | if (!ret) |
| 371 | return -1; |
Eric Andersen | bdfd0d7 | 2001-10-24 05:00:29 +0000 | [diff] [blame] | 372 | #ifdef CONFIG_FEATURE_FUNKY |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 373 | maybe_do_funky_stuff(bar, baz); |
| 374 | #endif |
| 375 | |
| 376 | Do this instead: |
| 377 | |
| 378 | (in .h header file) |
| 379 | |
Denis Vlasenko | e324184 | 2007-08-13 10:36:25 +0000 | [diff] [blame] | 380 | #if ENABLE_FEATURE_FUNKY |
| 381 | static inline void maybe_do_funky_stuff(int bar, int baz) |
Mark Whitley | d238a7b | 2001-02-09 00:28:59 +0000 | [diff] [blame] | 382 | { |
| 383 | /* lotsa code in here */ |
| 384 | } |
| 385 | #else |
Denis Vlasenko | e324184 | 2007-08-13 10:36:25 +0000 | [diff] [blame] | 386 | static inline void maybe_do_funky_stuff(int bar, int baz) {} |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 387 | #endif |
| 388 | |
| 389 | (in the .c source file) |
| 390 | |
| 391 | ret = my_func(bar, baz); |
| 392 | if (!ret) |
| 393 | return -1; |
| 394 | maybe_do_funky_stuff(bar, baz); |
| 395 | |
| 396 | The great thing about this approach is that the compiler will optimize away |
Mark Whitley | d238a7b | 2001-02-09 00:28:59 +0000 | [diff] [blame] | 397 | the "no-op" case (the empty function) when the feature is turned off. |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 398 | |
| 399 | Note also the use of the word 'maybe' in the function name to indicate |
| 400 | conditional execution. |
| 401 | |
| 402 | |
| 403 | |
| 404 | Notes on Strings |
| 405 | ---------------- |
| 406 | |
| 407 | Strings in C can get a little thorny. Here's some guidelines for dealing with |
| 408 | strings in Busybox. (There is surely more that could be added to this |
| 409 | section.) |
| 410 | |
| 411 | |
| 412 | String Files |
| 413 | ~~~~~~~~~~~~ |
| 414 | |
| 415 | Put all help/usage messages in usage.c. Put other strings in messages.c. |
| 416 | Putting these strings into their own file is a calculated decision designed to |
| 417 | confine spelling errors to a single place and aid internationalization |
| 418 | efforts, if needed. (Side Note: we might want to use a single file - maybe |
| 419 | called 'strings.c' - instead of two, food for thought). |
| 420 | |
| 421 | |
| 422 | Testing String Equivalence |
| 423 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 424 | |
| 425 | There's a right way and a wrong way to test for sting equivalence with |
| 426 | strcmp(): |
| 427 | |
| 428 | The wrong way: |
| 429 | |
| 430 | if (!strcmp(string, "foo")) { |
| 431 | ... |
| 432 | |
| 433 | The right way: |
| 434 | |
| 435 | if (strcmp(string, "foo") == 0){ |
| 436 | ... |
| 437 | |
| 438 | The use of the "equals" (==) operator in the latter example makes it much more |
| 439 | obvious that you are testing for equivalence. The former example with the |
| 440 | "not" (!) operator makes it look like you are testing for an error. In a more |
| 441 | perfect world, we would have a streq() function in the string library, but |
| 442 | that ain't the world we're living in. |
| 443 | |
| 444 | |
Mark Whitley | a5b55ca | 2001-01-24 00:18:13 +0000 | [diff] [blame] | 445 | Avoid Dangerous String Functions |
| 446 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 447 | |
| 448 | Unfortunately, the way C handles strings makes them prone to overruns when |
| 449 | certain library functions are (mis)used. The following table offers a summary |
| 450 | of some of the more notorious troublemakers: |
| 451 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 452 | function overflows preferred |
| 453 | ------------------------------------------------- |
| 454 | strcpy dest string safe_strncpy |
| 455 | strncpy may fail to 0-terminate dst safe_strncpy |
| 456 | strcat dest string strncat |
| 457 | gets string it gets fgets |
| 458 | getwd buf string getcwd |
| 459 | [v]sprintf str buffer [v]snprintf |
| 460 | realpath path buffer use with pathconf |
| 461 | [vf]scanf its arguments just avoid it |
Mark Whitley | a5b55ca | 2001-01-24 00:18:13 +0000 | [diff] [blame] | 462 | |
| 463 | |
| 464 | The above is by no means a complete list. Be careful out there. |
| 465 | |
| 466 | |
| 467 | |
| 468 | Avoid Big Static Buffers |
| 469 | ------------------------ |
| 470 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 471 | First, some background to put this discussion in context: static buffers look |
Mark Whitley | a5b55ca | 2001-01-24 00:18:13 +0000 | [diff] [blame] | 472 | like this in code: |
| 473 | |
| 474 | /* in a .c file outside any functions */ |
Rob Landley | 6a24976 | 2005-12-20 15:23:20 +0000 | [diff] [blame] | 475 | static char buffer[BUFSIZ]; /* happily used by any function in this file, |
Mark Whitley | a5b55ca | 2001-01-24 00:18:13 +0000 | [diff] [blame] | 476 | but ick! big! */ |
| 477 | |
| 478 | The problem with these is that any time any busybox app is run, you pay a |
| 479 | memory penalty for this buffer, even if the applet that uses said buffer is |
| 480 | not run. This can be fixed, thusly: |
| 481 | |
Eric Andersen | d35c215 | 2001-01-25 23:49:09 +0000 | [diff] [blame] | 482 | static char *buffer; |
Mark Whitley | a5b55ca | 2001-01-24 00:18:13 +0000 | [diff] [blame] | 483 | ... |
| 484 | other_func() |
| 485 | { |
| 486 | strcpy(buffer, lotsa_chars); /* happily uses global *buffer */ |
| 487 | ... |
| 488 | foo_main() |
| 489 | { |
| 490 | buffer = xmalloc(sizeof(char)*BUFSIZ); |
| 491 | ... |
| 492 | |
| 493 | However, this approach trades bss segment for text segment. Rather than |
| 494 | mallocing the buffers (and thus growing the text size), buffers can be |
| 495 | declared on the stack in the *_main() function and made available globally by |
| 496 | assigning them to a global pointer thusly: |
| 497 | |
Eric Andersen | d35c215 | 2001-01-25 23:49:09 +0000 | [diff] [blame] | 498 | static char *pbuffer; |
Mark Whitley | a5b55ca | 2001-01-24 00:18:13 +0000 | [diff] [blame] | 499 | ... |
| 500 | other_func() |
| 501 | { |
| 502 | strcpy(pbuffer, lotsa_chars); /* happily uses global *pbuffer */ |
| 503 | ... |
| 504 | foo_main() |
| 505 | { |
| 506 | char *buffer[BUFSIZ]; /* declared locally, on stack */ |
| 507 | pbuffer = buffer; /* but available globally */ |
| 508 | ... |
| 509 | |
Eric Andersen | d35c215 | 2001-01-25 23:49:09 +0000 | [diff] [blame] | 510 | This last approach has some advantages (low code size, space not used until |
| 511 | it's needed), but can be a problem in some low resource machines that have |
Mark Whitley | d238a7b | 2001-02-09 00:28:59 +0000 | [diff] [blame] | 512 | very limited stack space (e.g., uCLinux). |
| 513 | |
| 514 | A macro is declared in busybox.h that implements compile-time selection |
| 515 | between xmalloc() and stack creation, so you can code the line in question as |
| 516 | |
Eric Andersen | bdfd0d7 | 2001-10-24 05:00:29 +0000 | [diff] [blame] | 517 | RESERVE_CONFIG_BUFFER(buffer, BUFSIZ); |
Mark Whitley | d238a7b | 2001-02-09 00:28:59 +0000 | [diff] [blame] | 518 | |
| 519 | and the right thing will happen, based on your configuration. |
Mark Whitley | a5b55ca | 2001-01-24 00:18:13 +0000 | [diff] [blame] | 520 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 521 | Another relatively new trick of similar nature is explained |
| 522 | in keep_data_small.txt. |
| 523 | |
Mark Whitley | a5b55ca | 2001-01-24 00:18:13 +0000 | [diff] [blame] | 524 | |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 525 | |
| 526 | Miscellaneous Coding Guidelines |
| 527 | ------------------------------- |
| 528 | |
| 529 | The following are important items that don't fit into any of the above |
| 530 | sections. |
| 531 | |
| 532 | |
| 533 | Model Busybox Applets After GNU Counterparts |
| 534 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 535 | |
| 536 | When in doubt about the proper behavior of a Busybox program (output, |
| 537 | formatting, options, etc.), model it after the equivalent GNU program. |
| 538 | Doesn't matter how that program behaves on some other flavor of *NIX; doesn't |
| 539 | matter what the POSIX standard says or doesn't say, just model Busybox |
Mark Whitley | 7ddaf7c | 2001-03-14 21:04:53 +0000 | [diff] [blame] | 540 | programs after their GNU counterparts and it will make life easier on (nearly) |
| 541 | everyone. |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 542 | |
| 543 | The only time we deviate from emulating the GNU behavior is when: |
| 544 | |
| 545 | - We are deliberately not supporting a feature (such as a command line |
| 546 | switch) |
| 547 | - Emulating the GNU behavior is prohibitively expensive (lots more code |
| 548 | would be required, lots more memory would be used, etc.) |
Eric Andersen | 0730943 | 2000-11-29 22:12:19 +0000 | [diff] [blame] | 549 | - The difference is minor or cosmetic |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 550 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 551 | A note on the 'cosmetic' case: output differences might be considered |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 552 | cosmetic, but if the output is significant enough to break other scripts that |
| 553 | use the output, it should really be fixed. |
| 554 | |
| 555 | |
| 556 | Scope |
| 557 | ~~~~~ |
| 558 | |
| 559 | If a const variable is used only in a single source file, put it in the source |
| 560 | file and not in a header file. Likewise, if a const variable is used in only |
| 561 | one function, do not make it global to the file. Instead, declare it inside |
Eric Andersen | 0730943 | 2000-11-29 22:12:19 +0000 | [diff] [blame] | 562 | the function body. Bottom line: Make a conscious effort to limit declarations |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 563 | to the smallest scope possible. |
| 564 | |
| 565 | Inside applet files, all functions should be declared static so as to keep the |
| 566 | global name space clean. The only exception to this rule is the "applet_main" |
| 567 | function which must be declared extern. |
| 568 | |
| 569 | If you write a function that performs a task that could be useful outside the |
| 570 | immediate file, turn it into a general-purpose function with no ties to any |
| 571 | applet and put it in the utility.c file instead. |
| 572 | |
| 573 | |
| 574 | Brackets Are Your Friends |
| 575 | ~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 576 | |
| 577 | Please use brackets on all if and else statements, even if it is only one |
| 578 | line. Example: |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 579 | |
| 580 | Don't do this: |
| 581 | |
| 582 | if (foo) |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 583 | stmt1; |
| 584 | stmt2 |
| 585 | stmt3; |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 586 | |
| 587 | Do this instead: |
| 588 | |
| 589 | if (foo) { |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 590 | stmt1; |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 591 | } |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 592 | stmt2 |
| 593 | stmt3; |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 594 | |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 595 | The "bracketless" approach is error prone because someday you might add a line |
| 596 | like this: |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 597 | |
| 598 | if (foo) |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 599 | stmt1; |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 600 | new_line(); |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 601 | stmt2; |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 602 | stmt3; |
Mark Whitley | 40bfc76 | 2000-07-24 22:36:06 +0000 | [diff] [blame] | 603 | |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 604 | And the resulting behavior of your program would totally bewilder you. (Don't |
| 605 | laugh, it happens to us all.) Remember folks, this is C, not Python. |
| 606 | |
| 607 | |
| 608 | Function Declarations |
| 609 | ~~~~~~~~~~~~~~~~~~~~~ |
| 610 | |
| 611 | Do not use old-style function declarations that declare variable types between |
| 612 | the parameter list and opening bracket. Example: |
| 613 | |
| 614 | Don't do this: |
| 615 | |
| 616 | int foo(parm1, parm2) |
| 617 | char parm1; |
| 618 | float parm2; |
| 619 | { |
| 620 | .... |
| 621 | |
| 622 | Do this instead: |
| 623 | |
| 624 | int foo(char parm1, float parm2) |
| 625 | { |
| 626 | .... |
| 627 | |
| 628 | The only time you would ever need to use the old declaration syntax is to |
Eric Andersen | 0730943 | 2000-11-29 22:12:19 +0000 | [diff] [blame] | 629 | support ancient, antediluvian compilers. To our good fortune, we have access |
Mark Whitley | d58ff87 | 2000-11-22 19:25:39 +0000 | [diff] [blame] | 630 | to more modern compilers and the old declaration syntax is neither necessary |
| 631 | nor desired. |
| 632 | |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 633 | |
| 634 | Emphasizing Logical Blocks |
| 635 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 636 | |
| 637 | Organization and readability are improved by putting extra newlines around |
| 638 | blocks of code that perform a single task. These are typically blocks that |
| 639 | begin with a C keyword, but not always. |
| 640 | |
| 641 | Furthermore, you should put a single comment (not necessarily one line, just |
| 642 | one comment) before the block, rather than commenting each and every line. |
Mike Frysinger | 434ccd9 | 2006-07-05 22:19:21 +0000 | [diff] [blame] | 643 | There is an optimal amount of commenting that a program can have; you can |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 644 | comment too much as well as too little. |
| 645 | |
Mark Whitley | 7ddaf7c | 2001-03-14 21:04:53 +0000 | [diff] [blame] | 646 | A picture is really worth a thousand words here, the following example |
| 647 | illustrates how to emphasize logical blocks: |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 648 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 649 | while (line = xmalloc_fgets(fp)) { |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 650 | |
| 651 | /* eat the newline, if any */ |
Mark Whitley | 7ddaf7c | 2001-03-14 21:04:53 +0000 | [diff] [blame] | 652 | chomp(line); |
Mark Whitley | 3680c58 | 2000-12-20 22:35:12 +0000 | [diff] [blame] | 653 | |
| 654 | /* ignore blank lines */ |
| 655 | if (strlen(file_to_act_on) == 0) { |
| 656 | continue; |
| 657 | } |
| 658 | |
| 659 | /* if the search string is in this line, print it, |
| 660 | * unless we were told to be quiet */ |
| 661 | if (strstr(line, search) && !be_quiet) { |
| 662 | puts(line); |
| 663 | } |
| 664 | |
| 665 | /* clean up */ |
| 666 | free(line); |
| 667 | } |
Mark Whitley | 9ead689 | 2001-03-03 00:44:55 +0000 | [diff] [blame] | 668 | |
| 669 | |
| 670 | Processing Options with getopt |
| 671 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 672 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 673 | If your applet needs to process command-line switches, please use getopt32() to |
Mark Whitley | 9ead689 | 2001-03-03 00:44:55 +0000 | [diff] [blame] | 674 | do so. Numerous examples can be seen in many of the existing applets, but |
| 675 | basically it boils down to two things: at the top of the .c file, have this |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 676 | line in the midst of your #includes, if you need to parse long options: |
Mark Whitley | 9ead689 | 2001-03-03 00:44:55 +0000 | [diff] [blame] | 677 | |
| 678 | #include <getopt.h> |
| 679 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 680 | Then have long options defined: |
| 681 | |
| 682 | static const struct option <applet>_long_options[] = { |
| 683 | { "list", 0, NULL, 't' }, |
| 684 | { "extract", 0, NULL, 'x' }, |
Denis Vlasenko | 84f75b0 | 2007-04-15 11:50:41 +0000 | [diff] [blame] | 685 | { NULL, 0, NULL, 0 } |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 686 | }; |
| 687 | |
Mark Whitley | 9ead689 | 2001-03-03 00:44:55 +0000 | [diff] [blame] | 688 | And a code block similar to the following near the top of your applet_main() |
| 689 | routine: |
| 690 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 691 | char *str_b; |
| 692 | |
| 693 | opt_complementary = "cryptic_string"; |
| 694 | applet_long_options = <applet>_long_options; /* if you have them */ |
| 695 | opt = getopt32(argc, argv, "ab:c", &str_b); |
| 696 | if (opt & 1) { |
| 697 | handle_option_a(); |
| 698 | } |
| 699 | if (opt & 2) { |
| 700 | handle_option_b(str_b); |
| 701 | } |
| 702 | if (opt & 4) { |
| 703 | handle_option_c(); |
| 704 | } |
Mark Whitley | 9ead689 | 2001-03-03 00:44:55 +0000 | [diff] [blame] | 705 | |
| 706 | If your applet takes no options (such as 'init'), there should be a line |
| 707 | somewhere in the file reads: |
| 708 | |
| 709 | /* no options, no getopt */ |
| 710 | |
| 711 | That way, when people go grepping to see which applets need to be converted to |
| 712 | use getopt, they won't get false positives. |
| 713 | |
Denis Vlasenko | 91de7c0 | 2007-04-15 08:39:39 +0000 | [diff] [blame] | 714 | For more info and examples, examine getopt32.c, tar.c, wget.c etc. |