X-Git-Url: http://git.efficios.com/?p=lttng-tools.git;a=blobdiff_plain;f=CodingStyle;h=6ff931b150cc920ded9e7ba6807059a8fa814922;hp=180d097994a450e512d9ec218fc22c7fe8f67c0d;hb=25357057de5ae4dd2a572e8f9b893c1b90cbd60a;hpb=0c8a2a56138dc1e31e7cfa359cfc00f89f331fb7

diff --git a/CodingStyle b/CodingStyle
index 180d09799..6ff931b15 100644
--- a/CodingStyle
+++ b/CodingStyle
@@ -1,11 +1,132 @@
 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 either a single space or tabs to indent the '\' at the end of lines.
+Use tabs at the beginning of lines.
+
+Either:
+
+#define a_macro(x) \
+	do { \
+		fsync(); \
+	} while (0)
+
+or
+
+#define a_macro(x)		\
+	do {			\
+		fsync();	\
+	} while (0)
+
+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. */