]> git.ipfire.org Git - thirdparty/kmod.git/blob - CODING-STYLE
testsuite: give a more suitable description to test
[thirdparty/kmod.git] / CODING-STYLE
1 Every project has its coding style, and kmod is not an exception. This
2 document describes the preferred coding style for kmod code, in order to keep
3 some level of consistency among developers so that code can be easily
4 understood and maintained, and also to help your code survive under
5 maintainer's fastidious eyes so that you can get a passport for your patch
6 ASAP.
7
8 First of all, kmod coding style must follow every rule for Linux kernel
9 (http://www.kernel.org/doc/Documentation/CodingStyle). There also exists a tool
10 named checkpatch.pl to help you check the compliance with it. Just type
11 "checkpatch.pl --no-tree patch_name" to check your patch. In theory, you need
12 to clean up all the warnings and errors except this one: "ERROR: Missing
13 Signed-off-by: line(s)". kmod does not used Signed-Off lines, so including
14 them is actually an error. In certain circumstances one can ignore the 80
15 character per line limit. This is generally only allowed if the alternative
16 would make the code even less readable.
17
18 Besides the kernel coding style above, kmod coding style is heavily based on
19 oFono's and BlueZ's. Below some basic rules:
20
21 1) Wrap line at 80 char limit.
22
23 There are a few exceptions:
24 - Headers may or may not wrap
25 - If it's a string that is hitting the limit, it's preferred not to break
26 in order to be able to grep for that string. E.g:
27
28 err = my_function(ctx, "this is a long string that will pass the 80chr limit");
29
30 - If code would become unreadable if line is wrapped
31 - If there's only one argument to the function, don't put it alone in a
32 new line.
33
34 Align the wrapped line either with tabs (BlueZ, oFono, etc) or tab + spaces
35 (kernel), at your discretion. Kernel's is preferred.
36
37 2) It's better to return/exit early in a function than having a really long
38 "if (...) { }". Example:
39
40 if (x) { // worse | if (!x) // better
41 ... | return b;
42 ... |
43 ... | ...
44 ... | ...
45 ... | ...
46 ... | ...
47 ... | ...
48 ... | ...
49 } else { | ...
50 return b; | return a;
51 } |
52 |
53 return a; |
54
55 3) Don't initialize variable unnecessarily
56 When declaring a variable, try not to initialize it unless necessary.
57
58 Example:
59 int i = 1; // wrong
60
61 for (i = 0; i < 3; i++) {
62 }