]>
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 | ||
818af4f6 | 18 | Besides the kernel coding style above, kmod coding style is heavily based on |
836e4551 LDM |
19 | oFono's and BlueZ's. Below some basic rules: |
20 | ||
818af4f6 LDM |
21 | 1) Wrap line at 80 char limit. |
22 | ||
23 | There are a few exceptions: | |
836e4551 LDM |
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 | ||
818af4f6 LDM |
34 | Align the wrapped line either with tabs (BlueZ, oFono, etc) or tab + spaces |
35 | (kernel), at your discretion. Kernel's is preferred. | |
36 | ||
836e4551 LDM |
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 | } | |
5ca15057 LDM |
63 | |
64 | 4) Let the includes in the following order, separated by a new line: | |
65 | < system headers > | |
66 | < shared/* > | |
67 | < libkmod > | |
68 | < tool > | |
69 | "local headers" |