Fix: coding style document has erroneous semicolon at end of macro
[lttng-tools.git] / CodingStyle
index 180d097994a450e512d9ec218fc22c7fe8f67c0d..1d8bd9b43130847893e65ce09c533a89f282ca93 100644 (file)
 LTTng-Tools Coding Style
 
-The coding style used for this project follows the the Linux kernel
-guide lines, except that brackets "{", "}" should typically be used even
-for single-line if/else statements. Please refer to:
+Author: David Goulet
+Last Update: 13/11/2012
+
+Tabs VS Spaces:
+-------------
+
+Right, so our two cents in this endless war! This project uses TABS for one
+simple reason, the coder can choose whatever size or type his/her indentation
+is and can set the prefered coding style by replacing the tabs which each
+normally respected IDE/editor can do.
+
+For vim, here is what I used:
+
+  set shiftwidth=4
+  set noexpandtab
+
+There is one exception for which  we use space in this project is for enum,
+defines and macros values indentation. For instance:
+
+Use space to indent the the value so they fit when reading them all. Same goes
+for the #define below.
+
+enum my_enum {
+       value1     = 1,
+       value289   = 289,
+       ...
+};
+
+#define DEFAULT_VALUE_OF_SOME_SORT   6
+#define THE_ANSWER                   42
+
+Use space to indent the '\' at the end but tabs at the beginning.
+
+#define a_macro(x)      \
+       do {                \
+               fsync();        \
+       } while (0)
+
+It's really the only time we use spaces. For everything else, there is TABS! :)
+
+Here is a pretty cool vim macro that will highlight your whitespaces and spaces
+before tab. This helps a *LOT* when coding.
+
+" Show trailing whitepace and spaces before a tab:
+function MyTrail()
+    let no_hl_trail = ["man", "help"]
+    if index(no_hl_trail, &ft) >= 0
+        return
+    endif
+    syn match ErrorMsg /\s\+$\| \+\ze\t\|\t\+\ze / containedin=@NoTrail
+endfunction
+syn cluster NoTrail contains=ALL remove=cComment
+autocmd Syntax * call MyTrail()
+
+C Style:
+-------------
+
+The coding style used for this project follows the the Linux kernel guide
+lines, except that brackets "{", "}" should typically be used even for
+single-line if/else statements. Please refer to:
+
+- doc/kernel-CodingStyle.txt (copied from Linux 3.4.4 git tree).
 
-- Linux kernel Documentation/CodingStyle document for details,
 - Linux kernel scripts/checkpatch.pl for a script which verify the patch
   coding style.
 
-Mathieu Desnoyers, May 30, 2012
+For header files, please declare the following in this order:
+
+1) #defines
+       - Default values should go in: src/common/defaults.h
+       - Macros used across the project: src/common/macros.h
+
+2) Variables
+       - No _static_ in a header file! This is madness.
+       - Use _extern_ if the global variable is set else where.
+
+3) Function prototype
+
+Furthermore, respect the name spacing of files for each non-static symbol
+visiable outside the scope of the C file. For instance, for the utils.c file in
+libcommon, every call should be prefixed by "utils_*".
+
+Error handling:
+-------------
+
+We ask to use one single return point in a function. For that, we uses the
+"goto" statement for the error handling creating one single point for error
+handling and return code. See the following example:
+
+int some_function(...)
+{
+       int ret;
+       [...]
+
+       if (ret != 0) {
+               goto error;
+       }
+
+       [...]
+error:
+       return ret;
+}
+
+Commenting:
+-------------
+
+Every function MUST have a comment above it even if the function is trivial.
+
+Please add non-trivial comments/documentation as much as you can in the code.
+Poor comments WILL be rejected upon merging so please pay attention to this
+details because we do!
+
+If the comments requires more than one line, please format like so:
+
+/*
+ * Some comments which requires multiple
+ * lines [...]
+ */
+
+and on a single line:
+
+/* My comment on a single line. */
This page took 0.031969 seconds and 4 git commands to generate.