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

61–68 of 68 posts

Re: Plan 9 Coding Conventions for C

#61

Post by to3m »

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 seen it once, in 13 years of working professionally in C. I think two people changed the same one-line if statement, but for two different reasons (probably adding two different new features to the same bit of code). And after an automatic merge it became something like this:

    if(flag)
        set_other_flag=1;
        call_function();
(both lines necessary)

Anyway, it didn't take long to narrow it down to that bit of code but it took a few more minutes to figure out why the function was always getting called. I couldn't work out what was going on until I looked at the disassembly and was forced to reassess my opinion of what code was actually being compiled. Too much python in my diet, perhaps.

I remember being surprised at the time that it had taken so long for this to happen, and I made a mental note to keep an eye out for more occurrences. That was summer 2006, and I haven't seen it happen since.

Re: Plan 9 Coding Conventions for C

#62

Post by Luyt »

papsosouid wrote: post #53
mercurial wrote: post #27

Earlier quoted context omitted.

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.

You can do that with Python code, too.

https://github.com/hhatto/autopep8

Re: Plan 9 Coding Conventions for C

#63

Post by rcxdude »

enqk wrote: post #45
kleiba wrote: post #42

Earlier quoted context omitted.

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

printf("Legit code\n"); #if 0 /* bunch of code to comment out */ printf("Commented code\n"); #endif

Those do with fine in vim though (even using #if 1 and #else will highlight the #else as a comment)

Re: Plan 9 Coding Conventions for C

#64

Post by rcxdude »

lmm wrote: post #25
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.

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

Re: Plan 9 Coding Conventions for C

#65

Post by papsosouid »

Luyt wrote: post #62
papsosouid wrote: post #53

Earlier quoted context omitted.

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.

You can do that with Python code, too. https://github.com/hhatto/autopep8

Sort of, but not quite. It is quite easy to get situations where code is wrong because of indentation mistakes, copy+paste, etc. All autopep can do is make your wrong code look consistent. Languages with some sort of block delimiter can't get wrong in this manner, so it is safe to munge together random sources with various indenting messes and then just run a tool over them.

Re: Plan 9 Coding Conventions for C

#66

Post by mheathr »

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

Re: Plan 9 Coding Conventions for C

#67

Post by Mr_T_ »

jstanley wrote: post #5
peteretep wrote: post #3

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

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.

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

Re: Plan 9 Coding Conventions for C

#68

Post by glurgh »

aap_ wrote: post #59
glurgh wrote: post #15

Earlier quoted context omitted.

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.

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.

Post reply on HN