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