LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Mark I Manning IV <mark4@purplecoder.com>
To: linux-kernel@vger.kernel.org
Subject: Coding Style
Date: Fri, 19 Jan 2001 12:59:55 -0500
Message-ID: <3A68809B.E12EF3D9@purplecoder.com> (raw)


[-- 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

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

             reply index

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-19 17:59 Mark I Manning IV [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A68809B.E12EF3D9@purplecoder.com \
    --to=mark4@purplecoder.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git
	git clone --mirror https://lore.kernel.org/lkml/10 lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git