Proper Linux Kernel Coding Style
Based on article by Greg Kroah-Hartman
Why care?
- "Code formatting doesn't matter."
- "Why is your style better than mine?"
- "Doesn't affect compiled size."
- "Doesn't affect execution speed."
- "K&R style is out of date."
C code may look like this. Why not?
"many eyes"
I want to read your code.
I want you to read my code.
I want you to fix my bugs.
I want you to change my code.
I want to build on your code.
Style affects productivity
Lets people focus on substance, not style.
We need productive kernel programmers!
Indentation
Use tabs.
All tabs are 8 characters.
If your code is indenting too deeply, fix the code.
Indentation - examples
Bad:
for(i=0; i<SIZE-1; i++) {
c=A[k=i];
for(j=i+1; j<SIZE; j++)
if(c>A[j])
c=A[k=j];
A[k] = A[i];
A[i] = c;
}
Indentation - examples
Bad:
function() { ... for(i=0; i<SIZE; i++) if(A[i]>0) for(j=i+1; j<SIZE; j++) if(A[j]>A[i]) for(k=i;... ... }
Indentation - examples
Good:
for(i=0; i<SIZE; i++) {
A[i] = random()%MAX;
printf("%d%c",A[i],i==SIZE-1?'\n':' ');
}
for(i=0; i<SIZE-1; i++) {
c=A[k=i];
for(j=i+1; j<SIZE; j++)
if(c>A[j])
c=A[k=j];
A[k] = A[i];
A[i] = c;
}
for(i=0; i<SIZE; i++)
printf("%d%c",A[i],i==SIZE-1?'\n':' ');
Braces
- Opening brace last on the line.
- Closing brace first on the line:
if (x is true) { we do y }
- Exception for functions:
int function(int x) { body of function }
Use formating tools
- indent (scripts/Lindent)
- AStyle
- uncrustify
- IDE embedded
They have a lot of options, and especially when it comes to comment re-formatting you may want to take a look at the man page. But remember: it's not a fix for bad programming.
Variable and Function Naming
- Be descriptive.
- Be concise.
- No MixedCase.
- No encoding the type within the name.
- Global variables only when necessary.
- Local variables short and to the point.
Naming - examples
Bad:
CommandAllocationGroupSize
DAC960_V1_EnableMemoryMailboxInterface()
loop_counter
Good:
cmd_group_size
enable_mem_mailbox()
i
Functions
- Do one thing, and do it well.
- Short, one or two screens of text.
- OK to have longer function doing small different things.
- If more than 10 local variables, too complex.
Comments
Good to have, but must be done correctly.
Bad comments:
explain how code works
say who wrote the function
have last modified date
have other trivial things
Good comments:
explain what
explain why
should be at beginning of function
Unwritten rules
Use code that is already present. In particulary:
- string functions
- byte order functions
- linked lists
typedef is evil
evil evil evil!
It hides the real type of the variable.
Allows programmers to get into trouble:
large structures on the stack
large structures passed as return values
Can hide long structure definitions:
pick a better name
typedef just to signify a pointer type?
could you be lazier?
Well, mostly evil
Base system types
u8, u16, u32, u64, etc.
dev_t
list_t
Function pointers
No magic numbers
A "non-obvious" value that is hard coded
Fortunately, not many instances
Conclusions
- Read kernel.org/doc/html/v4.10/process/coding-style.html
- Follow it.
- Use formating tools.
- Do not use typedef.
Copy of deck
By matkunova
Copy of deck
- 689