From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <731be915ba87d1709cedd619aac23c0f@airmail.cc> References: <731be915ba87d1709cedd619aac23c0f@airmail.cc> From: "Digby R.S. Tarvin" Date: Sat, 7 Apr 2018 18:59:19 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000009350ba056945eeae" Subject: Re: [9fans] Plan 9's style(6) manual page Topicbox-Message-UUID: d3e8d5e0-ead9-11e9-9d60-3106f5b1d025 --0000000000009350ba056945eeae Content-Type: text/plain; charset="UTF-8" I disagree with your assertion that inserting space after 'if', 'for', 'while' etc is universal outside of Plan 9. I have never adopted that convention, and it looks ugly to me. That is probably because I learned C by reading the Unix kernel source code (6th Edition) which displays a preference for brevity. If you go back to Denis Ritchie's original C reference manual from 1974: https://www.bell-labs.com/usr/dmr/www/cman74.pdf you will find he was inconsistent - sometimes adding a space, sometimes not. Perhaps that is why there is no universally accepted style standard. If I had to justify my preference, I would probably say that if the round brackets were optional (as they are, for example, in pascal), then I would put in the space because they would be part of the expression. But I suspect my preference is mainly just habit and now my brain is wired for it. Richie does omit the space before brackets in a function declaration/call, and to me that is more consistent with omitting the space in other language elements which require a parenthesis after a keyword or identifier. I am not sure that there is always a (logical) reason. If the language does not mandate a style, then whatever you choose is valid. Most of the time it boils down to what you first encountered when learning the language. Once you get used to one style, source code becomes much harder to read if it follows a different style, so you need a good reason to change. It makes sense to be consistent within a project, so unfortunately it is sometimes necessary to put up with a different style. Generally project manager or company will arbitrate on which wins. I am normally in a position where I am the only one working on particular source files, so I convert them to my preferred style, and then reformat them according to the dictates of the project when I am finished. Sometimes there are arguments for a particular style change, like putting lvalues on the right of a binary comparison so that accidental use of an assignment operator would generate a compiler error, but to me the result is so ugly, and my days of making that sort of mistake so far in the past that I definitely prefer the standard idioms. I have changed from putting curly brackets on the same line as the if/while/for etc, because I find the structure of the program easier to read if the brackets line up with the opening bracket over the corresponding closing bracket. It seems more consistent with curly brackets around function bodies, it is easier to find forgotten parentheses, and I think the rule about spaces before braces becomes irrelevant. The only down side seems to be taking up an extra line. I am not so keen on the braces around single line blocks - I suppose two wasted lines must be exceeding my tolerance. I sometimes make an exception for nested if/while/for etc statements where, for example, it may not otherwise be clear which statement an 'else' is associated with.. The Plan 9 developers obviously decided it would be better to establish a standard early on, and I suppose unsurprisingly the majority followed the traditions of the Unix source. I am not sure about the rule on automatic variable initialization. That is the only one in your list which puzzles me. DigbyT On 7 April 2018 at 17:00, <8halfan@airmail.cc> wrote: > Just an amateur C programmer looking for answers. My main inspirations for > code > style is K&R 2nd edition and I'm curious about the instructions in Plan 9's > style(6) manual page (for reference, http://man.cat-v.org/plan_9/6/style). > I've > tried to think about the motivations, but not everything is as clear as it > seems. > > Going through style(6): > > no white space before opening braces. >> no white space after the keywords `if', `for', `while', etc. >> > > This is unique to Plan 9, it seems. I can't come up with a reason -- both > BSD > and Linux style use whitespace, and K&R does too, while Plan 9 doesn't. > Why? > > no braces around single-line blocks (e.g., `if', `for', and `while' >> bodies). >> > > Apologies, but I'll have to Go and do it anyway :) > > automatic variables (local variables inside a function) are never >> initialized at declaration. >> > > Why not? In order to reduce visual clutter? It seems like this should be > handled > case-by-case: in some situations this just wastes lines: > > int foo; > foo = 12; > func("blah", &foo); > > follow the standard idioms: use `x < 0' not `0 > x', etc. >> > > I'm guessing this is for consistency and more common coincidence with the > flow > of spoken language. > > don't write `!strcmp' (nor `!memcmp', etc.) nor `if(memcmp(a, b, c))'; >> always >> explicitly compare the result of string or memory comparison with zero >> using a >> relational operator. >> > > Was that a common programmer error? cmp functions should return 0 if the > arguments are identical. Smells like disaster in baking! > > and this is not an exhaustive list >> > > Is there anything missing? > > That's all. Thanks for your time. > > --0000000000009350ba056945eeae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I disagree with your assertion that inserting spa= ce after 'if', 'for', 'while' etc is universal outs= ide of Plan 9. I have never adopted that convention, and it looks ugly to m= e. That is probably because I learned C by reading the Unix kernel source c= ode (6th Edition) which displays a preference for brevity. If you go back t= o Denis Ritchie's original C reference manual from 1974:
https://www.bell-labs.com/usr/dmr/www/cman74.pdf
you will find he was inconsistent - someti= mes adding a space, sometimes not. Perhaps that is why there is no universa= lly accepted style standard. If I had to justify my preference, I would pro= bably say that if the round brackets were optional (as they are, for exampl= e, in pascal), then I would put in the space because they would be part of = the expression. But I suspect my preference is mainly just habit=C2=A0 and = now my brain is wired for it.=C2=A0=C2=A0Richie does omit the space = before brackets in a function declaration/call, and to me that is more cons= istent with omitting the space in other language elements which require a p= arenthesis after a keyword or identifier.

I am not = sure that there is always a (logical) reason. If the language does not mand= ate a style, then whatever you choose is valid. Most of the time it boils d= own to what you first encountered when learning the language. Once you get = used to one style, source code becomes much harder to read if it follows a = different style, so you need a good reason to change. It makes sense to be = consistent within a project, so unfortunately it is sometimes necessary to = put up with a different style. Generally project manager or company will ar= bitrate on which wins. I am normally in a position where I am the only one = working on particular source files, so I convert them to my preferred style= , and then reformat them according to the dictates of the project when I am= finished.=C2=A0

Sometimes there are arguments for a par= ticular style change, like putting lvalues on the right of a binary compari= son so that accidental use of an assignment operator would generate a compi= ler error, but
to me the result is so ugly, and my days of making= that sort of mistake so far in the past that I definitely prefer the stand= ard idioms. I have changed from putting curly brackets on the same line as = the if/while/for
etc, because I find the structure of the program= easier to read if the brackets line up with the opening bracket over the c= orresponding closing bracket. It seems more consistent with curly brackets = around function bodies, it is easier to find forgotten parentheses, and I t= hink the rule about spaces before braces becomes irrelevant. The only down = side seems to be taking up an extra line.

I am not= so keen on the braces around single line blocks - I suppose two wasted lin= es must be exceeding my tolerance. I sometimes make an exception for nested= if/while/for etc statements where, for example, it may not otherwise be cl= ear which statement an 'else' is associated with..
<= br>
The Plan 9 developers obviously decided it would be better to= establish a standard early on, and I suppose unsurprisingly the majority f= ollowed the traditions of the Unix source.

I am no= t sure about the rule on automatic variable initialization. That is the onl= y one in your list which puzzles me.=C2=A0

D= igbyT

= On 7 April 2018 at 17:00, <8halfan@airmail.cc> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Just an amateur C programmer looking for answ= ers. My main inspirations for code
style is K&R 2nd edition and I'm curious about the instructions in = Plan 9's
style(6) manual page (for reference, http://man.cat-v.org/plan_9/= 6/style). I've
tried to think about the motivations, but not everything is as clear as it<= br> seems.

Going through style(6):

no white space before opening braces.
no white space after the keywords `if', `for', `while', etc.

This is unique to Plan 9, it seems. I can't come up with a reason -- bo= th BSD
and Linux style use whitespace, and K&R does too, while Plan 9 doesn= 9;t. Why?

no braces around single-line blocks (e.g., `if', `for', and `while&= #39; bodies).

Apologies, but I'll have to Go and do it anyway :)

automatic variables (local variables inside a function) are never
initialized at declaration.

Why not? In order to reduce visual clutter? It seems like this should be ha= ndled
case-by-case: in some situations this just wastes lines:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 int foo;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 foo =3D 12;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 func("blah", &foo);

follow the standard idioms: use `x < 0' not `0 > x', etc.

I'm guessing this is for consistency and more common coincidence with t= he flow
of spoken language.

don't write `!strcmp' (nor `!memcmp', etc.) nor `if(memcmp(a, b= , c))'; always
explicitly compare the result of string or memory comparison with zero usin= g a
relational operator.

Was that a common programmer error? cmp functions should return 0 if the arguments are identical. Smells like disaster in baking!

and this is not an exhaustive list

Is there anything missing?

That's all. Thanks for your time.


--0000000000009350ba056945eeae--