The Five Coding Styles and Linux  

Jul 25, 2006 (08:31 AM)

A long time ago, there was a simple debate on what kind of indenting should you be using and where should you place curly braces: it was the dispute "ANSI vs. K&R".

I always was "the pro-ANSI guy", and I still use the ANSI way, except for when I try to avoid mixing styles in the same source file.

Not being involved in the development of Linux, I didn't care about their mandatory formatting/indenting style, until I ran over this paper by Linus Torvalds.

It's at the same time saying: "Coding style is very personal, and I won't force my views on anybody", whereas strongly bashing the GNU formatting/indenting style: "I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture."

It's nice to see how contradicting concepts can still contribute to the progress of GNU/Linux.

Recently though, I noticed that 4 years ago, Greg Kroah-Hartman forced the use of the Linux (Linus) coding standards in the kernel!

Here's his presentation at Linux Symposium 2002, and also two chat transcripts [1], [2], where Greg KH was saying:
  • "First off, read the Documentation/CodingStyle file in the kernel tree.
  • It lists a number of rules that should _always_ be followed."
It's also about the "Hungarian notation" (mixed case notation) being forbidden in the Linux code (Microsoft bashing, perhaps?), so that "CommandAllocationGroupSize" is forbidden, and "cmd_group_size" is allowed.

Let's see however what are the five existing coding styles:

The ANSI style of formatting/indenting:
namespace foospace {
int Foo()
{
    if (isBar)
    {
        bar();
        return 1;
    }
    else
        return 0;
}
}
The GNU style of formatting/indenting:
namespace foospace
  {
    int Foo()
      {
        if (isBar)
          {
            bar();
            return 1;
          }
        else
          return 0;
      }
  }
The Kernighan&Ritchie style of formatting/indenting:
namespace foospace {
int Foo() {
    if (isBar) {
        bar();
        return 1;
    } else
        return 0;
}
}
The Java style of formatting/indenting:
class foospace {
    int Foo() {
        if (isBar) {
            bar();
            return 1;
        } else
            return 0;
    }
}
The Linux kernel style of formatting/indenting:
namespace foospace
{
int Foo()
{
        if (isBar) {
                bar();
                return 1;
        } else
                return 0;
}
}

Let's summarize:

ANSI:
  • braces are opening and closing at the beginning of a new line (for functions) or right under the keyword (for commands)
  • braces for namespaces are opening attached to the pre-block code
  • a closing brace is always on a line of its own
  • function names are never indented
  • TABs are 4 spaces wide
  • else is aligned to if (continuation is aligned to the command keyword)

GNU:
  • braces are always indented, and always under the names
  • a closing brace is always on a line of its own
  • "everything that's different is always indented, including braces"
  • TABs are 2 spaces wide
  • else is aligned to if (continuation is aligned to the command keyword)

K&R:
  • braces are always opening attached to the pre-block code, and closing right under the keyword
  • function names are never indented
  • TABs are 2 spaces wide
  • else (a continuation of the same command) is attached to the closing brace

Java:
  • braces are always opening attached to the pre-block code, and closing right under the keyword
  • "everything that's different is always indented (except for unnecessary brace indents)"
  • TABs are 4 spaces wide
  • else (a continuation of the same command) is attached to the closing brace

Linux:
  • braces are always opening attached to the pre-block code (K&R style), and closing right under the keyword, except for functions
  • braces for functions are always under the names, i.e. opening on the next line (ANSI style)
  • function names are never indented
  • TABs are 8 spaces wide
  • else (a continuation of the same command) is attached to the closing brace

Wow. Do you think it's easy to contribute to the Linux kernel? Most people use the K&R style and this is partially compatible with the Linux coding style, but I'm using the ANSI style most of the time...

And I could never use 8 spaces-wide TABs...

P.S.:

1. Oh, BTW, the Python Style Guide recommends using a 4 spaces TAB.

2. Another discussion could be done on the usage of whitespaces in expressions and statements, like:
for(i=1;i<n;i++)
vs.
for(i=1; i<n; i++)
vs.
for(i = 1; i < n; i++)
vs.
for (i=1;i<n;i++)
vs.
for (i=1; i<n; i++)
vs.
for (i = 1; i < n; i++)

To distinguish keywords from functions/procedure calls, a classical C++ rule was to use spaces only after the keywords, but not between procedure names and their argument list. In the same time, the expressions (or the arguments) are separated by spaces:
if (strcmp(input_value, "done") == 0)
  ^                    ^
    ...;
for (expr1; expr2; expr3) {
   ^       ^      ^
    ...;
}
However, as of today, usage of spaces after keywords like if and for is discouraged by many coding standards.

Altavista Babelfish translation  [Français]  [Deutsch]  [Nederlands]  [Español]  [Português]  [Italiano]
0 (+0) comments so far      [view/add comments]       [permalink]
GNOME


1600 archived posts

RSS Feed  Add to My Yahoo!  Add to Google

Support the hosting fees!

• Wow! The first Phishing for 2006! (From Poland, with love...)
• Get rid of Beagle in FC5
• Song of the Dead: MyLinux 1/2006 as PDF!
• Feng Shui Wiring
• Bookmark: Unofficial FC4 Starter Guide at University of Latvia
• Don't miss these yum articles: http://www.ducea .c...
• yep... they changed the PLF addy again... now it's...
• ironically, they could use their nuclear power to ...
• It only makes sense if you're using KDE. As long a...
• Just wanted to say that my preffered chm viewer is...
• No, it was not diplomacy. It was stubbornness. ...
• What discussion on fedora-devel-list? Mozil la s...
• update your media and check again. all ths apli...
• Nay, it's *you* the one who's praising something "...
• Gaël Duval created with his Mandrake-Linux a ...
• Yeah, but manually saving each and every file... ...
• Long life vim :-) :set fileformat=unix...
• How will it look like? When I posted: http://b...
• well, i disagree, i can imagine Ulteo how it will ...
• * Nope. I don't fscking care what the Church prete...
• First of all, good thing you decided not to let th...
• OK, here are some clarifications: ***** ...
• I don't know how stable the PLF repos for 2007 are...
• OLPC is NOOOOOOOOOOOOOT non-profit!!! They will...
• I also don't see why Fedora shouldn't support the ...
• AlterSlash
• Debian Administration
• debian-bugs-dist
• DebianHelp UK
• Debuntu
• FootNotes
• FrSIRT Advisories
• GNOME Files
• Howtoforge
• Mandriva vu par Esfa
• MDLog:/sysadmin
• Nuxified
• Planet Debian
• tuxmachines




• Himself
• My resumé [PDF]

Amazon UK Wish List
Amazon US Wish List

Technorati Profile

[new login]


Reg'd 1996-08-26