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 Copy of deck

By Георгий Курячий