Difference between revisions of "User:Mnemoc/CodingStyle"
(→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()
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
- 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
- #ifdef Considered Harmful by Henry Spencer.
- Recommended C Style and Coding Standards (Indian Hill C style guide, amended) 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
- ↑ The Practice of Programming by Kernighan and Pike (ISBN: 0-201-61586-X).
- ↑ Kernel Walkthrough: Linux development background, file layout and data types by OCLUG.
- ↑ Linux System Programming, Talking Directly to the Kernel and C Library by Robert Love (ISBN:0-596-00958-5)
- Documentation/CodingStyle by Linux Torvalds.
- Proper Linux Kernel Coding Style by Greg Kroah-Hartman.
- A boring list of rules (aka A kernel guide to space) by Michael S. Tsirkin, and it's feedback in LKML.