Plan 9 Coding Conventions for C • Hacker News Board

Re: Plan 9 Coding Conventions for C

#21

Post by angersock » Wed, May 22, 2013, 12:57 PM UTC

jacobparker wrote: post #12

shin_lao wrote: post #2

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 (al…

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

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.

Re: Plan 9 Coding Conventions for C

#22

Post by angersock » Wed, May 22, 2013, 12:58 PM UTC

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.

Re: Plan 9 Coding Conventions for C

#23

Post by marios » Wed, May 22, 2013, 12:58 PM UTC

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

Re: Plan 9 Coding Conventions for C

#24

Post by doki_pen » Wed, May 22, 2013, 1:05 PM UTC

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

Re: Plan 9 Coding Conventions for C

#25

Post by lmm » Wed, May 22, 2013, 1:06 PM UTC

cypher543 wrote: post #19

[...] 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?

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

Re: Plan 9 Coding Conventions for C

#26

Post by oddthink » Wed, May 22, 2013, 1:08 PM UTC

shared4you wrote: post #18

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

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.

Re: Plan 9 Coding Conventions for C

#27

Post by mercurial » Wed, May 22, 2013, 1:11 PM UTC

jacobparker wrote: post #12

shin_lao wrote: post #2

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 (al…

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

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

Re: Plan 9 Coding Conventions for C

#28

Post by dietrichepp » Wed, May 22, 2013, 1:12 PM UTC

fijal wrote: post #8

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

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

Re: Plan 9 Coding Conventions for C

#29

Post by qznc » Wed, May 22, 2013, 1:13 PM UTC

jomar wrote: post #20

shin_lao wrote: post #17

Earlier quoted context omitted.

Because developer one wrote if (statement) one; And developper two added if (statement) one; two; too quickly

The actual problem there is that developer two checked something in without thinking about it, reading it, or examining the diffs of the change. If you had a coding convention of always using braces in if statements, you might be insulated from this particular symptom or instance of the problem, but you still have the underlying problem that people are doing things without thinking.

"you still have the underlying problem that people are doing things without thinking"

You can solve this problem?

Re: Plan 9 Coding Conventions for C

#30

Post by mercurial » Wed, May 22, 2013, 1:14 PM UTC

shin_lao wrote: post #17

gosu wrote: post #6

Earlier quoted context omitted.

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 rea…

Because developer one wrote if (statement) one; And developper two added if (statement) one; two; too quickly

Sure, but how often does this happen in practice? I have worked with 'no convention'/'multiple conventions'/'mostly no braces for single statements' and have never seen this particular mistake. I can see how it would be difficult to track down, on the other hand, braces for single comments add to line noise.