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, by 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."
Language
Linux is written in a flavour of C99 known as GNU C, 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:
register
case low ... high:
likely()
andunlikely()
(macros around__builtin_expect()
)typeof()
__alignof__()
inline
, a macro aroundinline __atribute__ ((always_inline))
__foo
, macros around__atribute__ ((foo))
, where foo can be one of: noinline, pure, const, noreturn, malloc, deprecated, used, unused and packed.__must_check
, a macro around__atribute__ ((warn_unused_result))
__align(x)
, a macro around__atribute__ ((aligned (x)))
__align_max
, a macro around__atribute__ ((aligned))
- and
__builtin_return_address()
.
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
Placing Braces and Spaces
Naming
Typedefs
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.
Centralized exiting of functions
Commenting
Kconfig configuration files
Data structures
Macros, Enums and RTL
Printing kernel messages
Allocating memory
The inline disease
Function return values and names
Don't re-invent the kernel macros
Editor modelines and other cruft
See also
- #ifdef Considered Harmful by Henry Spencer.
- Recommended C Style and Coding Standards (Indian Hill C style guide, updated) by Henry Spencer.
- Brian Kernighan's Programming Style Tips
- Notes on programming in C by Rob Pike.
- C Elements of Style by Steve Oualline.
References
- Documentation/CodingStyle by Linux Torvals.
- Proper Linux Kernel Coding Style by Greg Kroah-Hartman.
- A boring list of rules (aka A kernel guide to space), and it's feedback in LKML, by Michael S. Tsirkin.