Difference between revisions of "User:Mnemoc/CodingStyle"

From eLinux.org
Jump to: navigation, search
(Words of wisdom)
(Fixing a broken link.)
 
Line 69: Line 69:
 
* [http://www.eecs.harvard.edu/~ellard/CS50-95/programming-style.html Brian Kernighan's Programming Style Tips]
 
* [http://www.eecs.harvard.edu/~ellard/CS50-95/programming-style.html Brian Kernighan's Programming Style Tips]
 
* [http://www.lysator.liu.se/c/pikestyle.html Notes on programming in C] by Rob Pike.
 
* [http://www.lysator.liu.se/c/pikestyle.html Notes on programming in C] by Rob Pike.
* [http://www.oualline.com/style/index.html C Elements of Style] by Steve Oualline.
+
* [http://www.oualline.com/books.free/style/index.html C Elements of Style] by Steve Oualline.
  
 
==References==
 
==References==

Latest revision as of 10:04, 28 February 2016

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[1], 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 gcc, 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[2][3]:

  • 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

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

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