On Sun, 30 Sep 2007 13:40:13 -0400 Mark Lord wrote:

quoted text
> Erez Zadok wrote:
> > In message <alpine.LFD.0.999.0709291748160.3579@woody.linux-foundation.org>, Linus Torvalds writes:
> >>
> >> On Sat, 29 Sep 2007, Erez Zadok wrote:
> >>> Would you prefer if CodingStyle was reorganized or even split into (1)
> >>> general principles and (2) details?  Perhaps we need a CodingStylePrinciples
> >>> and a CodingStyleDetails?
> >> I'm certainly ok with the split into two files.
> >>
> >> What I'm not ok with is really important stuff (indentation), and then 
> >> mixing in silly rules ("parenthesis are bad in printk's"?)
> >>
> >> 		Linus
> > 
> > OK, looking at CodingStyle, I see two kinds of chapters.  The first is stuff
> > that's more generic to C, and the other is more specific to Linux and how
> > one codes in the linux kernel.  So I propose the following:
> > 
> > 1. we create a new file called CodingSuggestions
> > 
> > 2. we keep in CodingStyle the following chapters
> > 
> >    Chapter 1: Indentation
> >    Chapter 2: Breaking long lines and strings
> >    Chapter 3: Placing Braces and Spaces
> >    Chapter 4: Naming
> >    Chapter 5: Typedefs
> >    Chapter 6: Functions
> >    Chapter 7: Centralized exiting of functions
> >    Chapter 8: Commenting
> >    Chapter 9: You've made a mess of it
> > 
> >    Note: I'd suggest we rename the title of ch9 to "Custom Editor
> >    Programming/Indentation Modes" or something more descriptive.
> > 
> >    Chapter 10: Kconfig configuration files
> >    Chapter 11: Data structures
> >    Chapter 12: Macros, Enums and RTL
> >    Chapter 15: The inline disease
> >    Chapter 16: Function return values and names
> >    Chapter 18: Editor modelines and other cruft
> > 
> > 3. move the following chapters to CodingSuggestions:
> > 
> >    Chapter 13: Printing kernel messages
> >    Note: ch13 is the one which mentions the don't put parentheses around %d.
> > 
> >    Chapter 14: Allocating memory
> >    Chapter 17: Don't re-invent the kernel macros
> >    Chapter 19: branch prediction optimizations (the un/likely debacle)
> 
> Super.  And then, in the spirit of Linus's request,
> we can submit another patch that simply removes that second file
> completely from the kernel source tree!

or just revert CodingStyle to its contents of say 4 years ago.

quoted text
> Yay!  The suits actually lose for once!
> (okay, so I can fantasize if I want to).

Yep, you can.

The other losers are new contributors who get rejected for not
understanding implicit kernel coding styles and people who
get to try to explain to them on a repeating basis (if even
that happens).

or the kernel maintainers if coding style doesn't matter so much
and uglier code begins to be merged.

---
~Randy
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/