X-Git-Url: https://git.liburcu.org/?p=lttng-tools.git;a=blobdiff_plain;f=CodingStyle;h=6ff931b150cc920ded9e7ba6807059a8fa814922;hp=8833180d6979837fdf652ad3fbbd995253b924f0;hb=HEAD;hpb=da1d733c6d3aa870598abb1eff26436a4985e37b

diff --git a/CodingStyle b/CodingStyle
deleted file mode 100644
index 8833180d6..000000000
--- a/CodingStyle
+++ /dev/null
@@ -1,124 +0,0 @@
-LTTng-Tools Coding Style
-
-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 scripts/checkpatch.pl for a script which verify the patch
-  coding style.
-
-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. */