70 lines
		
	
	
		
			2.3 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
			
		
		
	
	
			70 lines
		
	
	
		
			2.3 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
Every project has its coding style, and kmod is not an exception. This
 | 
						|
document describes the preferred coding style for kmod code, in order to keep
 | 
						|
some level of consistency among developers so that code can be easily
 | 
						|
understood and maintained, and also to help your code survive under
 | 
						|
maintainer's fastidious eyes so that you can get a passport for your patch
 | 
						|
ASAP.
 | 
						|
 | 
						|
First of all, kmod coding style must follow every rule for Linux kernel
 | 
						|
(http://www.kernel.org/doc/Documentation/CodingStyle). There also exists a tool
 | 
						|
named checkpatch.pl to help you check the compliance with it. Just type
 | 
						|
"checkpatch.pl --no-tree patch_name" to check your patch. In theory, you need
 | 
						|
to clean up all the warnings and errors except this one: "ERROR: Missing
 | 
						|
Signed-off-by: line(s)". kmod does not used Signed-Off lines, so including
 | 
						|
them is actually an error.  In certain circumstances one can ignore the 80
 | 
						|
character per line limit.  This is generally only allowed if the alternative
 | 
						|
would make the code even less readable.
 | 
						|
 | 
						|
Besides the kernel coding style above, kmod coding style is heavily based on
 | 
						|
oFono's and BlueZ's. Below some basic rules:
 | 
						|
 | 
						|
1) Wrap line at 80 char limit.
 | 
						|
 | 
						|
There are a few exceptions:
 | 
						|
	- Headers may or may not wrap
 | 
						|
	- If it's a string that is hitting the limit, it's preferred not to break
 | 
						|
	  in order to be able to grep for that string. E.g:
 | 
						|
 | 
						|
		err = my_function(ctx, "this is a long string that will pass the 80chr limit");
 | 
						|
 | 
						|
	- If code would become unreadable if line is wrapped
 | 
						|
	- If there's only one argument to the function, don't put it alone in a
 | 
						|
	  new line.
 | 
						|
 | 
						|
Align the wrapped line either with tabs (BlueZ, oFono, etc) or tab + spaces
 | 
						|
(kernel), at your discretion. Kernel's is preferred.
 | 
						|
 | 
						|
2) It's better to return/exit early in a function than having a really long
 | 
						|
   "if (...) { }". Example:
 | 
						|
 | 
						|
   if (x) {	// worse	|	if (!x)			// better
 | 
						|
	   ...			|		return b;
 | 
						|
	   ...			|
 | 
						|
	   ...			|	...
 | 
						|
	   ...			|	...
 | 
						|
	   ...			|	...
 | 
						|
	   ...			|	...
 | 
						|
	   ...			|	...
 | 
						|
	   ...			|	...
 | 
						|
   } else {			|	...
 | 
						|
	   return b;		|	return a;
 | 
						|
   }				|
 | 
						|
				|
 | 
						|
   return a;			|
 | 
						|
 | 
						|
3) Don't initialize variable unnecessarily
 | 
						|
When declaring a variable, try not to initialize it unless necessary.
 | 
						|
 | 
						|
Example:
 | 
						|
int i = 1;  // wrong
 | 
						|
 | 
						|
for (i = 0; i < 3; i++) {
 | 
						|
}
 | 
						|
 | 
						|
4) Let the includes in the following order, separated by a new line:
 | 
						|
	< system headers >
 | 
						|
	< shared/* >
 | 
						|
	< libkmod >
 | 
						|
	< tool >
 | 
						|
	"local headers"
 |