Difference between revisions of "Code Styling Tips"

From eLinux.org
Jump to: navigation, search
(Proper Linux Kernel Coding Style: add thread about boring.txt and style)
(Proper Linux Kernel Coding Style)
Line 9: Line 9:
 
[http://www.linuxjournal.com/article/5780 Proper Linux Kernel Coding Style]
 
[http://www.linuxjournal.com/article/5780 Proper Linux Kernel Coding Style]
  
Michael S. Tsirkin made years ago a ''kernel guide to space'' aka [http://web.archive.org/web/20060703085439/http://www.mellanox.com/mst/boring.txt a boring list of rules] which can be used to start a non-rhetoric article about Coding Style. The related [http://thread.gmane.org/gmane.linux.kernel/317744 thread] in LKML worth to be read.
+
Michael S. Tsirkin made a [http://www.openfabrics.org/~mst/boring.txt kernel guide to space] (''a boring list of rules'')] which got polished on a worth reading [http://thread.gmane.org/gmane.linux.kernel/317744 thread] in LKML in 2005.
 
 
  
 
=== use of #ifdefs ===
 
=== use of #ifdefs ===

Revision as of 03:58, 24 August 2008

Here are some miscellaneous tips for good code styling:

Proper Linux Kernel Coding Style

See the kernel coding style guide in any kernel source tree at: Documentation/CodingStyle (Online here)

Greg Kroah-Hartman wrote some additional tips in his article: Proper Linux Kernel Coding Style

Michael S. Tsirkin made a kernel guide to space (a boring list of rules)] which got polished on a worth reading thread in LKML in 2005.

use of #ifdefs

Rob Landley writes:

Read: http://www.chris-lott.org/resources/cstyle/ifdefs.pdf

Personally, I tend to have symbols #defined to a constant 0 or 1 depending on whether or not a function is enabled, and then just use if(SYMBOL) as a guard and let the compiler's dead code eliminator take it out for me at compile time (because if(0) {blah;} shouldn't put any code in the resulting .o file with any optimizer worth its salt. Borland C for DOS managed simple dead code elimination 20 years ago...)