[9fans] Plan 9's style(6) manual page

[9fans] Plan 9's style(6) manual page

[8halfan]

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.

Re: [9fans] Plan 9's style(6) manual page

[Jules Merit]

[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]

That sums I.T. up

On Sat, Apr 7, 2018, 9:02 AM <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.
>
>

[-- Attachment #2: Type: text/html, Size: 2439 bytes --]

Re: [9fans] Plan 9's style(6) manual page

[Digby R.S. Tarvin]

[-- Attachment #1: Type: text/plain, Size: 5164 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 7666 bytes --]

Re: [9fans] Plan 9's style(6) manual page

[hiro]

don't follow or pretend to follow rules you don't understand. i agree
about the variable initialization example, it's totally fine to break
the style rule in that case IMO. but i'm biased, i'm already used to
people initializing all over the place.

Re: [9fans] Plan 9's style(6) manual page

[Ori Bernstein]

On Sat, 07 Apr 2018 19:00:37 +0300, 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.

The manpage explains the reasoning:

    Ultimately, the goal is to write code that fits in with the
    other code around it and the system as a whole.

So, most of the answers to your questions are simply that someone had a
preference early on. They wrote the code. If you want your code to fit
in with theirs, this is how to do it.

--
    Ori Bernstein

Re: [9fans] Plan 9's style(6) manual page

[tlaronde]

On Sat, Apr 07, 2018 at 01:14:33PM -0700, Ori Bernstein wrote:
> On Sat, 07 Apr 2018 19:00:37 +0300, 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.
> 
> The manpage explains the reasoning:
> 
>     Ultimately, the goal is to write code that fits in with the
>     other code around it and the system as a whole.
> 
> So, most of the answers to your questions are simply that someone had a
> preference early on. They wrote the code. If you want your code to fit
> in with theirs, this is how to do it.

Indeed. When there are almost as many rational arguments for or
against some choice, this means that the subject is not essential
(there is no "truth"). In this case, for engineering reasons, the
goal shall be consistency: one person ("the chief") decides.
Furthermore, if the code is consistent (in the---french---army we
say: "paumés mais groupés" i.e.  "lost but together") you can apply
regular expressions processing to the whole because there _are_ rules,
if in whatever future the "chief" decides differently...

-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Plan 9's style(6) manual page

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

Just use cb(1) and follow the house style.

http://man.cat-v.org/plan_9/1/cb


On Apr 7, 2018 1:21 PM, "Ori Bernstein" <ori@eigenstate.org> wrote:

On Sat, 07 Apr 2018 19:00:37 +0300, 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.

The manpage explains the reasoning:

    Ultimately, the goal is to write code that fits in with the
    other code around it and the system as a whole.

So, most of the answers to your questions are simply that someone had a
preference early on. They wrote the code. If you want your code to fit
in with theirs, this is how to do it.

--
    Ori Bernstein

[-- Attachment #2: Type: text/html, Size: 1541 bytes --]

Re: [9fans] Plan 9's style(6) manual page

[Rob Ote]

>     Ultimately, the goal is to write code that fits in with the
>     other code around it and the system as a whole.

The Go released a very good idea, go fmt
imho, it is a better way