Clean-up: fix '-Wformat' warnings on various platforms
[lttng-tools.git] / CodingStyle
... / ...
CommitLineData
1LTTng-Tools Coding Style
2
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 either a single space or tabs to indent the '\' at the end of lines.
35Use tabs at the beginning of lines.
36
37Either:
38
39#define a_macro(x) \
40 do { \
41 fsync(); \
42 } while (0)
43
44or
45
46#define a_macro(x) \
47 do { \
48 fsync(); \
49 } while (0)
50
51Here is a pretty cool vim macro that will highlight your whitespaces and spaces
52before tab. This helps a *LOT* when coding.
53
54" Show trailing whitepace and spaces before a tab:
55function 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
61endfunction
62syn cluster NoTrail contains=ALL remove=cComment
63autocmd Syntax * call MyTrail()
64
65C Style:
66-------------
67
68The coding style used for this project follows the the Linux kernel guide
69lines, except that brackets "{", "}" should typically be used even for
70single-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
77For header files, please declare the following in this order:
78
791) #defines
80 - Default values should go in: src/common/defaults.h
81 - Macros used across the project: src/common/macros.h
82
832) Variables
84 - No _static_ in a header file! This is madness.
85 - Use _extern_ if the global variable is set else where.
86
873) Function prototype
88
89Furthermore, respect the name spacing of files for each non-static symbol
90visiable outside the scope of the C file. For instance, for the utils.c file in
91libcommon, every call should be prefixed by "utils_*".
92
93Error handling:
94-------------
95
96We 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
98handling and return code. See the following example:
99
100int some_function(...)
101{
102 int ret;
103 [...]
104
105 if (ret != 0) {
106 goto error;
107 }
108
109 [...]
110error:
111 return ret;
112}
113
114Commenting:
115-------------
116
117Every function MUST have a comment above it even if the function is trivial.
118
119Please add non-trivial comments/documentation as much as you can in the code.
120Poor comments WILL be rejected upon merging so please pay attention to this
121details because we do!
122
123If the comments requires more than one line, please format like so:
124
125/*
126 * Some comments which requires multiple
127 * lines [...]
128 */
129
130and on a single line:
131
132/* My comment on a single line. */
This page took 0.023019 seconds and 4 git commands to generate.