User:Mnemoc/CodingStyle

This Guide to the Linux Coding Style aims to give easy rules on how to apply the coding style chosen by the Linux Kernel Community, so if you send patches to LKML people make comments about your design and implementation, and how to improve them, and not about how ugly it looks. A program shall keep a consistent style to let all developers work together efficiently, and like it or not Linux has already chosen one.

As the life of the programmer is easier when he only needs to follow one style, it's a good idea to try use this one also in C code which wont be sent to LKML.

Words of wisdom

 * Indentation shows structure, but which indentation style is best? Should the opening brace go on the same line as the if or on the next? Programmers have always argued about the layout of programs, but the specific style is much less important than its consistent application. Pick one style, preferably ours, use it consistently, and don't waste time arguing.
 * By the way, if you work on a program you didn't write, preserve the style you find there. When you make a change, don't use your own style even though you prefer it. The program's consistency is more important that your own, because it makes life easier for those who follow.
 * -- The Practice of Programming, Kernighan and Pike.

Rationale
The Linux Coding Style is sustained not just because of consistency with the rest of the code, or because that is how Linus likes it, but mostly by the statements that if you find hard to use this style in your code, it's probably because of bad design, and that ugly code is very likely to be buggy. "And don't waste time arguing."

This coding style is heavily inspired by K&R, and for deep rationale the version of the Indian Hill guide amended by Henry Spencer can answer many questions.


 * NOTE: If you are modifying a module which doesn't follow this style you have two choices, the first and recommended is to get the module's style fixed first, and then sending your modifications. The second is to use the same ugly style the module is already using in your modifications. Never mix styles in the same module.

Language
Linux is written in a flavour of C99 known as GNU C and implemented by, which has a few GNU Extensions that are heavily used and recommended. In most cases they are hidden behind a macro with nicer name, which are preferred. These extensions are :
 * and  (macros around  )
 * , a macro around
 * , macros around, where foo can be one of: noinline, pure, const, noreturn, malloc, deprecated, used, unused and packed.
 * , a macro around
 * , a macro around
 * , a macro around
 * and.
 * , a macro around
 * , a macro around
 * , a macro around
 * and.

Indentation

 * Use tab (and only tab) for indenting, space can be used for aligning.
 * tabs are 8 characters wide.

Whitespacing

 * Never more than one empty line in a row.
 * Never an empty line on the top or bottom of the file.
 * Never leave spaces (or tabs) at the end of a line.
 * Files shall end with a newline.
 * Only one statement per line.

Breaking long lines and strings

 * Lines are at most 80 characters wide, a couple of extra characters may be tolerated if you can justify them.

Functions

 * Functions have to be declared in header files, never in .c files, therefore never declare static functions.
 * Define static functions in the right order so you don't need to declare them.
 * Separate function definitions with one empty line.