User:Mnemoc/CodingStyle

From eLinux.org
Revision as of 15:19, 24 August 2008 by Mnemoc (talk | contribs) (Rationale)
Jump to: navigation, search

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() and unlikely() (macros around __builtin_expect())
  • typeof()
  • __alignof__()
  • inline, a macro around inline __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

References