CodingStyle

   1 LTTng-Tools Coding Style
   2
   3 Author: David Goulet
   4 Last Update: 13/11/2012
   5
   6 Tabs VS Spaces:
   7 -------------
   8
   9 Right, so our two cents in this endless war! This project uses TABS for one
  10 simple reason, the coder can choose whatever size or type his/her indentation
  11 is and can set the prefered coding style by replacing the tabs which each
  12 normally respected IDE/editor can do.
  13
  14 For vim, here is what I used:
  15
  16   set shiftwidth=4
  17   set noexpandtab
  18
  19 There is one exception for which  we use space in this project is for enum,
  20 defines and macros values indentation. For instance:
  21
  22 Use space to indent the the value so they fit when reading them all. Same goes
  23 for the #define below.
  24
  25 enum my_enum {
  26         value1     = 1,
  27         value289   = 289,
  28         ...
  29 };
  30
  31 #define DEFAULT_VALUE_OF_SOME_SORT   6
  32 #define THE_ANSWER                   42
  33
  34 Use either a single space or tabs to indent the '\' at the end of lines.
  35 Use tabs at the beginning of lines.
  36
  37 Either:
  38
  39 #define a_macro(x) \
  40         do { \
  41                 fsync(); \
  42         } while (0)
  43
  44 or
  45
  46 #define a_macro(x)              \
  47         do {                    \
  48                 fsync();        \
  49         } while (0)
  50
  51 Here is a pretty cool vim macro that will highlight your whitespaces and spaces
  52 before tab. This helps a *LOT* when coding.
  53
  54 " Show trailing whitepace and spaces before a tab:
  55 function MyTrail()
  56     let no_hl_trail = ["man", "help"]
  57     if index(no_hl_trail, &ft) >= 0
  58         return
  59     endif
  60     syn match ErrorMsg /\s\+$\| \+\ze\t\|\t\+\ze / containedin=@NoTrail
  61 endfunction
  62 syn cluster NoTrail contains=ALL remove=cComment
  63 autocmd Syntax * call MyTrail()
  64
  65 C Style:
  66 -------------
  67
  68 The coding style used for this project follows the the Linux kernel guide
  69 lines, except that brackets "{", "}" should typically be used even for
  70 single-line if/else statements. Please refer to:
  71
  72 - doc/kernel-CodingStyle.txt (copied from Linux 3.4.4 git tree).
  73
  74 - Linux kernel scripts/checkpatch.pl for a script which verify the patch
  75   coding style.
  76
  77 For header files, please declare the following in this order:
  78
  79 1) #defines
  80         - Default values should go in: src/common/defaults.h
  81         - Macros used across the project: src/common/macros.h
  82
  83 2) Variables
  84         - No _static_ in a header file! This is madness.
  85         - Use _extern_ if the global variable is set else where.
  86
  87 3) Function prototype
  88
  89 Furthermore, respect the name spacing of files for each non-static symbol
  90 visiable outside the scope of the C file. For instance, for the utils.c file in
  91 libcommon, every call should be prefixed by "utils_*".
  92
  93 Error handling:
  94 -------------
  95
  96 We ask to use one single return point in a function. For that, we uses the
  97 "goto" statement for the error handling creating one single point for error
  98 handling and return code. See the following example:
  99
 100 int some_function(...)
 101 {
 102         int ret;
 103         [...]
 104
 105         if (ret != 0) {
 106                 goto error;
 107         }
 108
 109         [...]
 110 error:
 111         return ret;
 112 }
 113
 114 Commenting:
 115 -------------
 116
 117 Every function MUST have a comment above it even if the function is trivial.
 118
 119 Please add non-trivial comments/documentation as much as you can in the code.
 120 Poor comments WILL be rejected upon merging so please pay attention to this
 121 details because we do!
 122
 123 If the comments requires more than one line, please format like so:
 124
 125 /*
 126  * Some comments which requires multiple
 127  * lines [...]
 128  */
 129
 130 and on a single line:
 131
 132 /* My comment on a single line. */