Difference between revisions of "Code Styling Tips"
Peter Huewe (talk | contribs) (added sparse) |
m (Fixed link for Henry Spencer's coding style document.) |
||
Line 14: | Line 14: | ||
Rob Landley writes: | Rob Landley writes: | ||
− | Read: http:// | + | Read: http://doc.cat-v.org/henry_spencer/ifdef_considered_harmful.pdf |
Personally, I tend to have symbols #defined to a constant 0 or 1 depending on | Personally, I tend to have symbols #defined to a constant 0 or 1 depending on | ||
Line 22: | Line 22: | ||
with any optimizer worth its salt. Borland C for DOS managed simple dead | with any optimizer worth its salt. Borland C for DOS managed simple dead | ||
code elimination 20 years ago...) | code elimination 20 years ago...) | ||
− | |||
== See also == | == See also == |
Latest revision as of 08:55, 27 February 2012
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://doc.cat-v.org/henry_spencer/ifdef_considered_harmful.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...)