CodingStyle

   1 If you start a new file, you get to choose the style.
   2 If you change an existing file, follow the existing style.
   3
   4 Hard tabs are OK, as long as you consider the tab stops to
   5 be every 8 characters. You can also use 2, 3, or 4 spaces.
   6 Tabs are kind of yucky, since cut-and-paste mangles them
   7 sometimes and they make "diff -Naurd old new" output less
   8 readable.
   9
  10 Spaces within a line don't matter much, and won't be
  11 considered part of the style. Just make it readable:
  12
  13 if(x){            // OK
  14 if( x ){           // OK
  15 if (x) {            // OK
  16 if(x==y && a==b){     // OK
  17 if(x == y && a == b){ // poor
  18 if(x==y&&a==b){       // poor
  19
  20 This is evil:
  21
  22 szWinStallman
  23 FoulCodingStyle (int iInsanity)
  24   {
  25      if (iInsanity)
  26        {
  27           GoHackEmacs () ;
  28        }
  29           else
  30        {
  31           SeekHelpForYourLisp () ;
  32        }
  33   }
  34
  35
  36 Curly braces belong at the end of a line. If you must, go ahead
  37 and make function bodies an exception to that rule. (as Linus does)
  38
  39 Big fprintf() calls and similar go like this:
  40
  41 fprintf(fd, "%d %d %d %d %d %d\n",
  42   sdfsdf_sdfsdf + sdfs_iii,     // not an example of good names!
  43   iijjij,
  44   kjfkkj_sdfssss_sfff,
  45   sdflkjfdskj + sdf - sfds,
  46   jksss,
  47   sfssss + wwwwfwfw
  48 );
  49
  50 Keep these distinct: NULL, '\0', 0, 0.0
  51
  52 Command-line parsers need to be bomb-proof. It is not acceptable
  53 to crash due to a messed up command-line. For an option "-x" that
  54 takes an argument, accept both "-x arg" and "-xarg". Remember to
  55 support "--" and "--version".
  56
  57 Be extremely careful when handling data from other users.
  58 For example, it is a security hole if /proc/123/cmdline can
  59 overflow an array. It is often a security hole if you allow
  60 non-ASCII characters to be printed. Assuming the console is
  61 not in UTF-8 mode, all of these are bad: "\b\e\f\n\r\t\v\x9b".
  62 (the "\x9b" is valid in UTF-8 mode, but equivalent to "\e["
  63 when not in UTF-8 mode -- which gives control of terminal
  64 settings) It's best if you consider user-supplied data to
  65 be unsafe, since this makes for less work in case the code
  66 ends up needing to run setuid. Termcap data is user-supplied.
  67 Except for the above security issues, don't bother to check
  68 for something you can't handle... like printf() failing.
  69 It is expected that /dev exists and so on.
  70
  71 Remember that a read() may return early, with partial data
  72 or with -1 and errno set to EINTR. You then must try again.
  73
  74 char:      may be signed or unsigned by default
  75 int:       always 32-bit
  76 long long: always 64-bit
  77 pointer:   either 32-bit or 64-bit
  78 long:      same size as a pointer
  79 KLONG:     same size as a pointer or long IN THE KERNEL
  80
  81 Functions used in just one file must be marked static.
  82 Use the "const" and "restrict" keywords wherever you can.
  83
  84 Put main() at the bottom of a file so you don't need all
  85 those ugly forward declarations.
  86
  87 Avoid the strcat() function. It is slow. For some odd
  88 reason, snprintf() is faster than sprintf().
  89
  90 Reuse memory allocations when you can. When using realloc(),
  91 do your increments by more than one. 25% is a nice amount.
  92
  93 Avoid compile-time choices. They make documentation difficult,
  94 and they are not friendly to binary distribution.
  95
  96 Write programs that can handle a million processes without
  97 getting hopelessly slow. Allow for /proc/123/cmdline to
  98 be at least 128 kB.
  99
 100 The LGPL license is strongly preferred. This allows use of
 101 the code in the library.