]>
Commit | Line | Data |
---|---|---|
836e4551 LDM |
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 havily based on | |
19 | oFono's and BlueZ's. Below some basic rules: | |
20 | ||
21 | 1) Wrap line at 80 char limit. There are a few exceptions: | |
22 | - Headers may or may not wrap | |
23 | - If it's a string that is hitting the limit, it's preferred not to break | |
24 | in order to be able to grep for that string. E.g: | |
25 | ||
26 | err = my_function(ctx, "this is a long string that will pass the 80chr limit"); | |
27 | ||
28 | - If code would become unreadable if line is wrapped | |
29 | - If there's only one argument to the function, don't put it alone in a | |
30 | new line. | |
31 | ||
32 | 2) It's better to return/exit early in a function than having a really long | |
33 | "if (...) { }". Example: | |
34 | ||
35 | if (x) { // worse | if (!x) // better | |
36 | ... | return b; | |
37 | ... | | |
38 | ... | ... | |
39 | ... | ... | |
40 | ... | ... | |
41 | ... | ... | |
42 | ... | ... | |
43 | ... | ... | |
44 | } else { | ... | |
45 | return b; | return a; | |
46 | } | | |
47 | | | |
48 | return a; | | |
49 | ||
50 | 3) Don't initialize variable unnecessarily | |
51 | When declaring a variable, try not to initialize it unless necessary. | |
52 | ||
53 | Example: | |
54 | int i = 1; // wrong | |
55 | ||
56 | for (i = 0; i < 3; i++) { | |
57 | } |