linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Coding Style
@ 2001-01-19 17:59 Mark I Manning IV
  2001-01-20  0:09 ` David Ford
                   ` (3 more replies)
  0 siblings, 4 replies; 52+ messages in thread
From: Mark I Manning IV @ 2001-01-19 17:59 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

Hi ppl..  This is my first posting here and it will probably generate
MORe flames than any previous posting but that isnt realy my intent,. 
The attached doccument is My answer to teh linux Coding Style doc as
found in teh kernel sources bz2.  It is done in parody of teh original
doc and is meant to be laughed at as much as taken seriously.... no
offense is intended towards the original author :)

Anyway, here goes  -->

[-- Attachment #2: CodingStyle --]
[-- Type: text/plain, Size: 6483 bytes --]



  An answer to the Linux kernel coding style 

This is a short document describing the preferred coding style for any
sane project.  Coding style is very personal, and I won't _force_ my
views on anybody, but please at least consider the points made here. 

First off, I'd suggest printing out a copy of the GNU coding standards,
and NOT reading it.  Burn them, it's a great symbolic gesture.  

Anyway, here goes:


    Chapter 1: Indentation

Tabs are 8 characters so NO tabs should be used in ANY source file what 
so ever.  There are some silly people that insist on hitting the tab key 
when they should really be hitting the SPACE key (and for your info Linus
PI is EXACTLY 3... ish :)

Rationale:  Tabs force your code out to the right edge of the display
leaving no room for comments.  You don't need great big gaping spaces to
delineate the start and end of a block, TWO spaces do this just fine.


    Chapter 2: Placing Braces

The other issue that always comes up in C styling is the placement of
braces.  Unlike the indent size, there are few technical reasons to
choose one placement strategy over the other.  The most ridiculous way
is shown to us by the idiots Kernighan and Ritchie.  I.E, to put the 
opening brace last on the line, and put the closing brace first, thusly:

  if (x is true) {
    we do y              // original text failed to comment here
  }

Functions are not a special case simply because they can't be nested, 
they just happen to be the only thing K&R brace correctly.  Anyway, 
nesting if, and & but loops is evil.

  int function(int x)   
  {
    body of function    // correctly braced and commented :)
  }

Sane people all over the world have claimed that the K&R inconsistency
is...  well...  inconsistent, and they are all right-thinking people
who know that (a) K&R are _wrong_ and (b) K&R are very wrong.

Note that the closing brace is empty on a line of its own, _except_ in
the cases where it is followed by a continuation of the same statement,
ie a "while" in a do-statement or an "else" in an if-statement, like
this:

  do
  {
    body of do-loop     // why do you insist on not commenting ?
  } while (condition);  // more on this later :)         

Linus states that the placement of the first brace at the end of the 
first line keeps your code less vertical and thus saves you some space
for comments.  This commenting style just plane sucks, it fragments your
source file creating all kinds of visual clutter making them impossible 
to read.  New lines ARE A RENEWABLE resource, if they aren't then you need 
to buy more ram for your 8086 (or is it a z80 ?).

code code code
{
  code code code
}

comment comment comment

code code code

comment comment

code
{
  code

  comment

  code
}

...looks like shit....

code code code          // comment comment comment
{
  code code code        // comment comment comment
}

code code code          // comment comment

code                    // comment
{
  code                  // comment
  code                  // comment
}

...is much neater and also takes up allot less vertical space (thus
blowing the argument Linus was making about braces eating up 
real estate).  Yes we could shrink this further by bracing as per
K&R but that would only serve to cram everything into an unreadable
blob.  SOME whitespace IS needed!!

One other thing.  Allot of people neglect to brace a statement if 
it has a single line body.  This is VERY bad, always brace your
statements....

 if (x = 1)
   if (y = 2)
     if (z = 3)
       for (i = 1; i < 10; i++)
         if ....
           switch (foo)
             .....

...is really stupid.  DON'T DO IT!

    Chapter 3: Naming

Just read the document written by Linus, he is 100% correct here,
Hungarian notation is not only brain damaged it is brain damaging.
I know, I was forced to use it once and I am defiantly brain 
damaged :)

Oh... yea... that bit about function growth hormone imbalance 
syndrome was cute man :)
	
	
    Chapter 4: Functions

Again, I point you in the direction of the original document.

I would however like to state that the C switch statement is evil and
to be avoided at all costs.  If you really need to use one for what 
ever reason then each case in that switch statement should be a
CALL TO A FUNCTION!  Never place the source for that function inline 
unless it is only ONE line of code (or at a push TWO lines).  You can 
always make the compiler inline it for you!!!

Rationale.  

 switch(foo)
 {
   case 1:
   ...   500 lines of code
   case 2:                      // at this point ALL context for the
   ...  500 lines of code       // switch is lost. I.E. unreadable!
 }         

Even if its only 9 or 10 lines of code you STILL lose context on the
switch statement.  Poorly factored code is difficult to read. Very few
C coders know how to factor their code well.


    Chapter 5: Commenting

Comments are good, the more you comment your code the better. These
comments are not for you, they are for the poor schmuck that has to 
deal with your scratching later.  Never underestimate the stupidity
of this guy, don't leave anything to chance.  Never assume that HE 
will understand your logic simply because YOU do.

Rationale.  If you have thunked about your code enough to comment
it then you have thunked about it enough to CODE IT!


    Chapter 6: You've made a mess of it

Just read what Linus wrote.  Oh... Linus, its AN infinite number not
A infinite number...  and erm... what's emacs ??


    Chapter 7:  Configuration-files

Read what Linus wrote here, its a classic example of how to be totally
inconsistent.  Indentation should be 3 here but 2 there and 8 over 
there and 10 in this file but don't go over 29 in this file here... 

DOH!

-----------------------------------------------------------------------

Ok.. So I'm a heretic... I admit it!

I have never really liked the C language, it seems to me that it has a
habit of making ANY idiot think he/she can be a coder.  C is an easy 
language to learn but to be a good C coder takes years of hard study
and a TRUE artistic flair for programming.  This means that 99% of all 
C code is JUNK code.  

Before you all go running for your 1911 45 ACP's and 30-06's Linux is 
most defiantly in the 1% here, I just don't like the source format :P~  

Comments and flames are welcome....

Mark I Manning IV                  mark4@purplecoder.com

-----------------------------------------------------------------------    

^ permalink raw reply	[flat|nested] 52+ messages in thread
[parent not found: <Pine.LNX.4.10.10101192217390.9361-100000@penguin.transmeta .com>]
* RE: Coding Style
@ 2001-01-23 15:07 Jonathan Earle
  2001-01-24  3:23 ` john slee
  0 siblings, 1 reply; 52+ messages in thread
From: Jonathan Earle @ 2001-01-23 15:07 UTC (permalink / raw)
  To: 'Linux Kernel List'

> -----Original Message-----
> From: adrian
> 
> On Mon, 22 Jan 2001, Mark I Manning IV wrote:
> 
> > It is alot neater tho :P~
> >
> > // even for multi line comments
> > // no visual clutter over there -->
> 
> /*
>  * I tend to find standard C comments easier to read.  They stand out,
>  * especially for multiple lines (although I always try to put the :end:
>  * on a separate line for clarity).
>  */

I like this style for multiple line comments, but prefer the '//' for single
liners.  Two less characters to type after all.  :)
 
> int function(int x)
> {
> 	/* Bleh.  Comments take up space.
> 	 */
> 	function body;
> }

int function(int x) {
 	// I like comments.  'Sides, what else would you use the space for?
 	function body;
}

Cheers!
Jon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 52+ messages in thread
* coding style
@ 2007-06-14 18:48 Cyrill Gorcunov
  2007-06-15  4:51 ` Willy Tarreau
  0 siblings, 1 reply; 52+ messages in thread
From: Cyrill Gorcunov @ 2007-06-14 18:48 UTC (permalink / raw)
  To: LKML


Hi to all,

a simple question the answer to witch I didn't find in CodingStyle.
Look for a code snip:

	err = foo(arg_a, arg_b, arg_c,
		arg_d);

the second line contains 'd' arg aligned with tabs only
but it could be rewritten with more elegant style (by adding
a few spaces) like this

	err = foo(arg_a, arg_b, arg_c,
		  arg_d);

so which one is preferred for the kernel?

		Cyrill


^ permalink raw reply	[flat|nested] 52+ messages in thread

end of thread, other threads:[~2007-06-19 14:05 UTC | newest]

Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-01-19 17:59 Coding Style Mark I Manning IV
2001-01-20  0:09 ` David Ford
2001-01-20  1:26   ` John Cavan
2001-01-20  0:46 ` Albert D. Cahalan
2001-01-20  5:34   ` Linus Torvalds
2001-01-21  2:00 ` Matthias Andree
2001-01-22  8:24   ` Ralf Baechle
2001-01-22 22:28     ` Mark I Manning IV
2001-01-23  3:56       ` adrian
2001-01-23 20:05 ` Boris Dragovic
     [not found] <Pine.LNX.4.10.10101192217390.9361-100000@penguin.transmeta .com>
     [not found] ` <3A68E309.2540A5E1@purplecoder.com>
2001-01-20  6:29   ` Linus Torvalds
2001-01-20 15:32   ` Anton Altaparmakov
2001-01-21  8:24     ` george anzinger
2001-01-23 15:07 Jonathan Earle
2001-01-24  3:23 ` john slee
2007-06-14 18:48 coding style Cyrill Gorcunov
2007-06-15  4:51 ` Willy Tarreau
2007-06-15  5:09   ` Kok, Auke
2007-06-15  6:38     ` dave young
2007-06-15  6:47       ` debian developer
2007-06-15  6:54         ` dave young
2007-06-15  9:16       ` Jan Engelhardt
2007-06-15 17:32         ` Cyrill Gorcunov
2007-06-15 17:54           ` Chris Friesen
2007-06-15 18:03             ` Randy Dunlap
2007-06-15 19:10               ` Jan Engelhardt
2007-06-15 19:18                 ` Cyrill Gorcunov
2007-06-15 19:21                   ` Kok, Auke
2007-06-15 19:29                     ` Cyrill Gorcunov
2007-06-15 19:31                     ` Jan Engelhardt
2007-06-15 19:41                       ` Cyrill Gorcunov
2007-06-15 20:21                         ` Linus Torvalds
2007-06-15 20:35                           ` Jan Engelhardt
2007-06-16 12:30                             ` Stefan Richter
2007-06-15 20:21                         ` Jan Engelhardt
2007-06-15 20:39                           ` Linus Torvalds
2007-06-16  6:38                             ` Jan Engelhardt
2007-06-16 12:40                               ` Stefan Richter
2007-06-16 15:49                               ` Linus Torvalds
2007-06-19 14:05                                 ` Mark Lord
2007-06-15 19:45                       ` Kok, Auke
2007-06-15 19:49                         ` Cyrill Gorcunov
2007-06-15 20:28                         ` Jan Engelhardt
2007-06-15 22:10                   ` Randy Dunlap
2007-06-15 18:05             ` Kok, Auke
2007-06-15 18:22               ` Cyrill Gorcunov
2007-06-16 13:07                 ` Stefan Richter
2007-06-16 14:31                   ` gorcunov
2007-06-16 17:43                     ` Stefan Richter
2007-06-16 18:22                       ` Cyrill Gorcunov
2007-06-16 14:22         ` Clifford Wolf
2007-06-15  8:56     ` Krzysztof Halasa

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox