Plan 9 Coding Conventions for C

http://plan9.bell-labs.com/magic/man2html/6/style

by angersock • 13 years ago

63 65 13 years ago

shin_lao2• 13 years ago

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;

gosu2• 13 years ago

OS code has to do a lot of validating input and braceful style causes functions to be visually dominated by boring validation code. It's also surprisingly nice to have a visual distinction between boring conditions like if(!found) return; and the more interesting branches that require the braces.

Not sure I follow you on the one; two; example. Why would you have two statements per line in the first place? (You do realize that the "two;" isn't in the if block, right?)

shin_lao2• 13 years ago

Because developer one wrote

if (statement) one;

And developper two added

if (statement) one; two;

too quickly

ibotty• 13 years ago

but two statements in one line is not exactly encouraged by the rules either.

snov• 13 years ago

my favorite is

  if (statement)
  //  one;
    two;

jacobparker2• 13 years ago

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

angersock2• 13 years ago

Just see that made me foam at the mouth a little...grr.

We generally don't even like have non-curlied one-liners in our conditionals.

mercurial2• 13 years ago

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

nteon• 13 years ago

I can't stand macro comments - it makes it impossible to figure out whats going on without being sure to open the file in a specific editor with a specific project loaded. Say you have a separate lib project used by an application - if you open up an individual file from that lib while working on the application in Visual Studio it won't have the necessary context to 'comment out' macro comments. Its also hostile to people who use vi and emacs.

kleiba• 13 years ago

Sorry if I'm unenlightened... but what are macro comments?

papsosouid5• 13 years ago

>I appreciate that these are old rules

They are current rules also. The rules are largely the same as BSD rules, and go rules. Just because they are old, doesn't mean the people who wrote them moved on to doing what the trendy javascript kids do.

mheathr• 13 years ago

I always use braces in order to protect my future self from my current self. I don't want to end up introducing a logic error in the program because I overlooked proper scope while less coherent later on.

peteretep• 13 years ago

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

jstanley• 13 years ago

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.

_pmf_• 13 years ago

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

It's C99 (I also only saw it in C99 articles, never in production code). See http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Designated-Inits...

pdw2• 13 years ago

A variation of this syntax was standardized in C99:

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

It works for structs too:

    struct blah needfid = {
        .version = 0,
        .flush = 0,

glurgh2• 13 years ago

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]

Mr_T_• 13 years ago

See "3.5 Initialization indexes": http://plan9.bell-labs.com/sys/doc/compiler.html

fijal• 13 years ago

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

That sounds odd

dietrichepp• 13 years ago

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

rat87• 13 years ago

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.

emillon• 13 years ago

In the standard there is a notion of "significant prefix length". ie, your symbol names may actually be truncated. In C89 the minimum guaranteed length for exported symbols was 6 (IIRC) which explains why the libc symbols are so terse. Adding underscores would greatly reduce the number of significant characters (of course, all of this is mostly obsolete these days).

davidw• 13 years ago

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.

shared4you• 13 years ago

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

oddthink• 13 years ago

I think most places enforce the opposite. There's a strain of very-little-space style out there, but I'm not sure where it comes from. Maybe Pike, for all I know: http://www.literateprogramming.com/pikestyle.pdf is certainly rife with it.

qznc2• 13 years ago

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

maw3• 13 years ago

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.

cypher543• 13 years ago

[...] 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• 13 years ago

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

rcxdude2• 13 years ago

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

angersock2• 13 years ago

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• 13 years ago

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

marios• 13 years ago

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... [2] http://www.openbsd.org/cgi-bin/man.cgi?query=style&sekti...

doki_pen• 13 years ago

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

zxcdw• 13 years ago

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

papsosouid5• 13 years ago

It isn't a question of "modern" or "old". GNU has always had absurdly terrible styles rules for example. It isn't a "modern" thing at all.

kstenerud• 13 years ago

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

realrocker• 13 years ago

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

gioele• 13 years ago

> * no tabs expanded to spaces.

Oh, finally.

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

nnq• 13 years ago

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

papsosouid5• 13 years ago

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

JulianMorrison• 13 years ago

Someone needs to write "c fmt"

Plan 9 Coding Conventions for C

Related Stories