Lucas De Marchi | 836e455 | 2011-12-15 00:43:54 -0200 | [diff] [blame] | 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 | |
Lucas De Marchi | 818af4f | 2013-04-23 20:33:13 -0300 | [diff] [blame] | 18 | Besides the kernel coding style above, kmod coding style is heavily based on |
Lucas De Marchi | 836e455 | 2011-12-15 00:43:54 -0200 | [diff] [blame] | 19 | oFono's and BlueZ's. Below some basic rules: |
| 20 | |
Lucas De Marchi | 818af4f | 2013-04-23 20:33:13 -0300 | [diff] [blame] | 21 | 1) Wrap line at 80 char limit. |
| 22 | |
| 23 | There are a few exceptions: |
Lucas De Marchi | 836e455 | 2011-12-15 00:43:54 -0200 | [diff] [blame] | 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 | |
Lucas De Marchi | 818af4f | 2013-04-23 20:33:13 -0300 | [diff] [blame] | 34 | Align the wrapped line either with tabs (BlueZ, oFono, etc) or tab + spaces |
| 35 | (kernel), at your discretion. Kernel's is preferred. |
| 36 | |
Lucas De Marchi | 836e455 | 2011-12-15 00:43:54 -0200 | [diff] [blame] | 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 | } |
Lucas De Marchi | 5ca1505 | 2015-01-14 12:33:10 -0200 | [diff] [blame] | 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" |