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