
Plan 9 Coding Conventions for C - angersock
http://plan9.bell-labs.com/magic/man2html/6/style
======
shin_lao
I appreciate that these are old rules, nevertheless, I have the following
comments:

 _don't use // comments; some old Plan 9 code does, but we're converting it as
we touch it. We do sometimes use // to comment–out a few lines of code._

Doesn't make sense with any decent editor, you ought to comment via macros.

 _no braces around single–line blocks (e.g., if, for, and while bodies)_

I kind of like enforcing the opposite (always use braces).

Otherwise you end up with things like:

    
    
       if (statement)
          one; two;

~~~
jacobparker
And don't forget:

    
    
        if(a)
            if(b)
                x;
        else
            y;
    

This doesn't do what the indentation implies.
(<http://en.wikipedia.org/wiki/Dangling_else>)

Walter Bright (creator of D, etc.) has an article where he discusses his
interesting choice to make that grammar form illegal in D. He mentions that
after doing this he found a bug in D's runtime library.
<http://www.drdobbs.com/cpp/dangling-else-yet-again/231602010>

~~~
mercurial
This makes a good point for Python syntax, where you can't by construction end
up in situations like that.

~~~
maw
True, but the flip side is that in Python automatic indentation cannot
possibly work.

~~~
safod
Why not? vim indents one more when encountering a colon at the end of a line.
It also de-indents when encountering a return or break statement. Of course in
all other cases you have to de-indent manually, however, hitting backspace
once is not more work than typing a closing curly brace.

~~~
maw
What I mean is that you can't tell your editor to indent an arbitrary block of
code.

~~~
sp332
Right, because a block of un-indented python is syntactically incorrect. It
would be just like stripping all the brackets out of some C code and asking
the editor to add brackets to the resulting mess properly.

------
davidw
I am kind of partial to Tcl's C code:

<https://github.com/tcltk/tcl/blob/master/generic/tclConfig.c>

Although I think arguing for less uppercase/camelcase would not be entirely
out of place. Still though, it's very nice to read.

------
marios
The efficiency and comments part read like a tl;dr version of Kernighan & Pike
The Practice of Programming[1], which, I might add, is an excellent read. As
for coding conventions, I quite like OpenBSD's (man style)[2], which are also
present on FreeBSD. Though I rarely write C these days, I have to read some
every now and then, and code from BSD projects following those conventions
feels very readable.

[1] [http://www.amazon.com/Practice-Programming-Addison-Wesley-
Pr...](http://www.amazon.com/Practice-Programming-Addison-Wesley-Professional-
Computing/dp/020161586X) [2] [http://www.openbsd.org/cgi-
bin/man.cgi?query=style&sekti...](http://www.openbsd.org/cgi-
bin/man.cgi?query=style&sektion=9)

------
doki_pen
It's funny that many modern style rules are the exact opposite of these ones.

~~~
zxcdw
Which ones, in which languages and in what kind of projects?

------
fijal
* variable and function names are all lowercase, with no underscores.

That sounds odd

~~~
dietrichepp
Not really. Look at everything in the C standard library: fopen(), strcmp(),
malloc(), etc.

~~~
rat87
yes and c stdlib style naming is mainly considered legacy these days and multi
word "variable and function [in] all lowercase, with no underscores" is
frowned upon.

------
gioele
> * no tabs expanded to spaces.

Oh, finally.

Tabs for indentation levels, spaces for alignment. How hard can it be?

~~~
nnq
hard. someone even made a comic to explain how hard:
<http://www.emacswiki.org/SmartTabs>

~~~
papsosouid
That comic doesn't explain anything. That post also doesn't explain how hard
it is.

------
shared4you

         >  no white space after the keywords if, for, while, etc.
    

Woh, my workplace enforces the exact opposite! The idea is that if, while, etc
are not functions, therefore `if (x)` is unacceptable but `my_func(x)` is ok.
I personally prefer `if(x)` though.

~~~
qznc
There is no right or wrong here. The important thing is consistency across a
project.

~~~
maw
Spaces before parens doesn't matter too much, but with respect to spaces
before commas all relativism goes straight out the window: putting a space
before a comma is objectively better practice.

------
kstenerud
Odd that they don't like gotos. That's going to make cleanup code pretty ugly.

------
peteretep
eg: <http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/ramfs.c>

~~~
jstanley
Anybody know what the:

    
    
      int needfid[] = {
    	[Tversion] 0,
    	[Tflush] 0,
    	[Tauth] 0,
    

syntax means? Is this some Plan 9 extension, or is it just something I've
never encountered?

EDIT: I guess the value in the []'s is the array index to set the value of.

~~~
glurgh
That's right, it's a designated initializer, except the standard c99 way
requires an =. gcc didn't/doesn't but that's nonstandard. So it is an
extension, just not a plan9 one - a gcc-ism. clang's error/warning, as usual,
is very helpful so it's worth it just to try clang when running into weirdness
like that:

    
    
        warning: use of GNU 'missing =' extension in designator
              [-Wgnu-designator]

~~~
aap_
Well, it _is_ a Plan 9 extension. You made it sound like it was only a gcc
extension.

~~~
glurgh
You're right, it's described in 3.5 of

<http://plan9.bell-labs.com/sys/doc/compiler.html>

It seems like it was contemporaneous with the proposed c90 extension and also
supported the = except optionally. But it was definitely something in the plan
9 compiler rather than only a gcc thing.

------
cypher543
_[...] don't try to write the most compact code possible but rather the most
readable._

Don't conventions 6, 7, 8, and 11 violate this?

~~~
lmm
Braces around single-statement if/for/while make the code less readable, not
more.

~~~
rcxdude
depends entirely on what you're used to. I personally find the opposite is
true.

------
realrocker
Go plug: I first read about these conventions in a Go article[1].
[1]<http://talks.golang.org/2012/splash.article#TOC_5>.

------
JulianMorrison
Someone needs to write "c fmt"

------
angersock
Probably my favorite take-away from this:

 _"Ultimately, the goal is to write code that fits in with the other code
around it and the system as a whole. If the file you are editing already
deviates from these guidelines, do what it does. After you edit a file, a
reader should not be able to tell just from coding style which parts you
worked on."_

This is a real boon to other people on your team.

~~~
comatose_kid
Most good professionals I have worked with adhere to this simple rule.

