Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Plan 9 Coding Conventions for C

plan9.bell-labs.com

Post reply on HN
Print view View original

51–60 of 68 posts

Re: Plan 9 Coding Conventions for C

#51

Post by loup-vaillant »

zimpenfish wrote: post #33
jomar wrote: post #20

Earlier quoted context omitted.

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.

Why not take advantage of every safety net you can? People are fallible, mistakes get made.

Because if you do, the safety net will collapse your circus tent by their sheer weight.

The actual argument has been made in sibling comments: braces are verbose, and the mistake we speak of is exceedingly rare in practice. For simple one-liners, the verbosity costs more than the lack of safety net.

Re: Plan 9 Coding Conventions for C

#52

Post by gosu »

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

I think that such a developer would be equally as likely to forget to free() memory or overflow a buffer. I assume that the reasoning is that people who don't know C well enough or are too forgetful shouldn't be working on the Plan9 codebase anyway, so why optimize for such a bad case when there are definite costs to doing so (as I mentioned before)?

Re: Plan 9 Coding Conventions for C

#53

Post by papsosouid »

mercurial wrote: post #27
jacobparker wrote: post #12

Earlier quoted context omitted.

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.

As maw points out, that is not a pure win, it is a tradeoff. And it is a tradeoff that I've found to be a really bad one. Being able to run indent over your code and have it automatically formatted is really helpful in large, long term projects where people come and go and weren't effectively forced into using one style.

Re: Plan 9 Coding Conventions for C

#54

Post by k3n »

mercurial wrote: post #30
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

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.

I've encountered it just enough times to avoid it 100%. I think in my scenario, the problems have been compounded by an overall lax (lazy) coding style on the part of my predecessors, in that many of them were junior devs who virtually made-up their own coding styles. These devs treated whitespace like it cost money, and avoided any unrequired use of spaces, tabs, and newlines.

These types of conventions -- no curlies around simple blocks -- aren't too bad if a) your devs are adequately seasoned, and b) your devs believe in whitespace.

For instance, this isn't really so bad:

    if (foo)
      foo();
    else
      bar();
Hell, that's clean!

But it's stuff like this that causes issues:

    if(foo)foo();
    else bar();
Sometimes I'm lucky and find this:

    if (foo)
      foo();
    else {
      bar();
      baz();
    }
The best is abominations like this though; first, the sane formatting:

    if (foo)
      while (i++
Or, as I have found it:

    if(foo)while(i++
Seriously, that's enough for me to revoke commit privs.

Re: Plan 9 Coding Conventions for C

#55

Post by papsosouid »

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…

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

Re: Plan 9 Coding Conventions for C

#56

Post by papsosouid »

nnq wrote: post #50
gioele wrote: post #48

> * no tabs expanded to spaces. Oh, finally. Tabs for indentation levels, spaces for alignment. How hard can it be?

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

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

Re: Plan 9 Coding Conventions for C

#59

Post by aap_ »

glurgh wrote: post #15
jstanley wrote: post #5

Earlier quoted context omitted.

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.

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]

Well, it is a Plan 9 extension. You made it sound like it was only a gcc extension.

Re: Plan 9 Coding Conventions for C

#60

Post by sp332 »

maw wrote: post #49
safod wrote: post #44

Earlier quoted context omitted.

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.

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

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.
Post reply on HN