Coding standards

[jdallen2000]

... particularly irksome when it comes to issues of code layout style

Let me give my two-cents' worth. I'll start with a question
for the `indent' users.

One almost gets the impression that two guys in adjacent
cubicles run their own customized `indent' whenever sharing
code. If you get a paper printout, do you OCR it and `indent'
the result? I'm not being sarcastic; I just don't understand
the fascinated reliance on `indent.' (Below I mention some
problems `indent' will introduce.)

* * * * * * * * * * * * * * * *

In some ways, treatment of C coding style should be similar
to treatment of English writing style. When the N.Y. Times
hires a new editor, they give him a style guide -- I doubt
if it contains a lot of injunctions against things like
run-on sentences, rather it clarifies whether to leave
double-spaces between sentences, and whether to write
"Mr Jones" or to put a period after Mr.

Thus I found it odd that some suggested indentation and
white-space conventions were not a proper topic for a C style
guide. In English, when two words are separated by a comma,
the comma precedes the space, but the space would precede
a left parenthesis. Someone who insisted on reversing this
would be very irritating. Why should C be any different?

Someone taught me to write better English. "Place commas
inside the close quote," he said, "and don't start sentences
with `But.'" Even though I have a rebellious nature, I happily
adopted the first rule: defying punctuation conventions would
have no purpose. But for blunt emphasis, I still start some
sentences with `But.'

Similarly, in C we always write "if (foo(bar))" without
debating whether "if( foo (bar))" is better a priori.
We might *discourage* the nesting of (x ? y : z) operators
if afraid the code would be maintained by novices, but we
would not *forbid* it.

Because the C language and its programmers are flexible and
forgiving, some people may not realize that C white-space rules
are standardized, but the True Style for Coding C is no secret:
you can look at programming examples from Bill Joy or almost any
of the Great Names. Here's a small fragment, essentially in
True Style, from the Linux kernel:

if (!cap_issubset(inheritable,
cap_combine(target->cap_inheritable,
current->cap_permitted))) {
goto out;
}

In addition to showing the proper placement of braces, this example
is interesting because of the way a long expression is broken
into multiple lines, with spacing used to make a nested parameter
list more readable. (I mightn't do it quite like this, but only
because I mostly stick to TAB's for extended spacing.)

I know almost nothing about the `indent' utility. Can it produce
the spacing above automatically? And suppress it when shorter
names make it unnecessary? I know about `#ifndef lint'; is there
some sort of `#ifndef indent' when one wants to preserve a helpful
white-space arrangement?

Hmmm. When I nest expressions of (x ? y : z), I tend to use
line-breaks and spacing to make the logic easy-to-see.
Maybe that's why the `indent' fans seemed to disparage
such nesting -- in their environment the helpful spacing
will tend to be expunged!

It may seem I'm contradicting myself -- advocating strict
adherence to the True Style, yet condoning multi-line
expressions and other deviations. But a deviation and
its purpose will stand out clearly when the style is
otherwise consistent. Some of you are proud of your
non-True Styles and your consistency within that alien
universe, but this reminds me of a Richard Feynman anecdote.
Feynman invented his own trigonometric notation as a youngster.
He was a great genius and his notation was probably superior,
but he abandoned it as soon as he learned the standard and
realized his formulae were going to be read by others.

* * * * * * * * * * * * * * * *

Well, I'd planned on ranting on and on, but I see the ladies
and gentlemen of the jury are getting tired. As you deliberate,
remember that Simplicity is a premier virtue in programming.
The defendants are accused of making every white-space deviation
a legitimate code-style choice (to paraphrase Rush Limbaugh),
and of requiring me to run `indent' to avoid getting dizzy when
I need to look at their code. Since `indent' will obliterate
any special spacing, as in the above fragment or nested ternarys,
they acknowledge that they don't use spacing creatively.
Unless you find that these perverse ideas are indeed a mode
of Simplicity, you must vote to convict.

James Dow Allen


* * * * * * * * * * * * * * * *

 

[infobahn]

Similarly, in C we always write "if (foo(bar))" without
debating whether "if( foo (bar))" is better a priori.

Which "we" are you talking about? It doesn't include me.

I write if(foo(bar) != 0)

Because the C language and its programmers are flexible and
forgiving, some people may not realize that C white-space rules
are standardized,

But they are not.

> but the True Style for Coding C is no secret:

and no standard, either.

you can look at programming examples from Bill Joy or almost any
of the Great Names. Here's a small fragment, essentially in
True Style, from the Linux kernel:

if (!cap_issubset(inheritable,
cap_combine(target->cap_inheritable,
current->cap_permitted))) {
goto out;
}

In addition to showing the proper placement of braces,

Hardly. It's a common style, but its mindshare seems to be diminishing.


this example

is interesting because of the way a long expression is broken
into multiple lines, with spacing used to make a nested parameter
list more readable. (I mightn't do it quite like this, but only
because I mostly stick to TAB's for extended spacing.)

Readable? I don't think so. I'd simplify the expression, tidy up
the white space, and fix the flow control. Then, maybe, it would
be readable.

I know almost nothing about the `indent' utility. Can it produce
the spacing above automatically? And suppress it when shorter
names make it unnecessary? I know about `#ifndef lint'; is there
some sort of `#ifndef indent' when one wants to preserve a helpful
white-space arrangement?

The whole point of indent is that you run code through it to
convert it to your style, making it easier for you to read.
Then, if you need to check it back into CVS, you run the
code through it again, this time to convert it to the house
style. That way, you don't screw up diff with mere whitespace
changes, and everyone's happy. Bye bye holy war.

 

[Ben Pfaff]

Which "we" are you talking about? It doesn't include me.

I write if(foo(bar) != 0)

And I write `if (foo (bar))', assuming foo() returns a "boolean"
result.

It's nonsense to make statements like jdallen2000's above.

 

[Natt Serrasalmus]

Which "we" are you talking about? It doesn't include me.

I write if(foo(bar) != 0)

I find that form really annoying and when I see it in others code. It
suggests to me that the person who wrote it doesn't understand boolean
variables and the C idiom that was established with the C standard library.
The idiom I am referring to is that functions should return a value that
answers the question "Did anything go wrong and if so what was it?". By that
idiom then it should be obvious to any C programmer worth their pay that

if(strcmp(string1, string2))

means "Did anything go wrong (not match up) when comparing these two
strings?" (if I wanted to know how far off they were I'd save the return
value to a variable and evaluate that, but rarely does anyone ever care how
far off the comparison was, other functions may have more interesting
non-zero return codes.)

This form also encourages the early exit from a function:

if(strcmp(string1, string2))
return;

If you doubt me, look at K&R where you can find numerous examples of this
form and the early exit from functions.

This may seem awkward at first, but you get used to it. You should also get
used to writing your own functions in the same idiom, such that they return
zero for success and non-zero (with a value that indicates the level of
failure) for failure. This will preserve the idiom throughout the code.

A similar form that is particularly annoying is

if(foo(bar) == TRUE) /* where true is a macro defined as some non-zero
value */
{
(indented code for the entire rest of the function)
}
return somestatusvariable;

when it should be

if(!foo(bar))
return NONZEROSTATUSVALUE;
(code for the entire rest of the function now not indented so far)

(note also that some may have different notions as to what TRUE should be
defined as: -1, 1 etc. which makes the test against TRUE not just
idiomatically awkward, but potentially dangerous.)

Even worse is

if(a == b)
{
c = TRUE;
}
else
{
c = FALSE;
}

which should be

c = a == b;


or even worse than that

if(a == b)
{
c = FALSE;
}
else
{
c = TRUE;
}

which should be

c = !(a == b);


Some of you may be laughing at these last two examples, but don't. I've seen
it too many times that it's not funny any more.

But they are not.


and no standard, either.


Hardly. It's a common style, but its mindshare seems to be diminishing.

I hope its mindshare is dimishing. I would have written the above as:

if (!cap_issubset(inheritable,
cap_combine(target->cap_inheritable,
current->cap_permitted)))
goto out;

This way arguments to functions are lined up. There's no need for any braces
at all, so leave them out leaving fewer braces to worry about which ones
match which. The "goto out" statement could probably be a return statement
or a few cleanup statements (freeing pointers?) and a return statement (in
which case then braces would be needed and I'd prefer to see them lined up).

this example

Readable? I don't think so. I'd simplify the expression, tidy up
the white space, and fix the flow control. Then, maybe, it would
be readable.


The whole point of indent is that you run code through it to
convert it to your style, making it easier for you to read.
Then, if you need to check it back into CVS, you run the
code through it again, this time to convert it to the house
style. That way, you don't screw up diff with mere whitespace
changes, and everyone's happy. Bye bye holy war.

I do agree with you on that.

 

[Keith Thompson]

I find that form really annoying and when I see it in others code. It
suggests to me that the person who wrote it doesn't understand boolean
variables and the C idiom that was established with the C standard library.
The idiom I am referring to is that functions should return a value that
answers the question "Did anything go wrong and if so what was it?". By that
idiom then it should be obvious to any C programmer worth their pay that

if(strcmp(string1, string2))

means "Did anything go wrong (not match up) when comparing these two
strings?" (if I wanted to know how far off they were I'd save the return
value to a variable and evaluate that, but rarely does anyone ever care how
far off the comparison was, other functions may have more interesting
non-zero return codes.)

Personally, I don't think of the result of strcmp() as a boolean
value. It's effectively a tri-state value, one of <0, 0, or >0
depending on the result of the comparison. I prefer an explicit
comparison:

if (strcmp(string1, string2) != 0) ...

If the function's name implied that it tests whether the arguments
differ, I might feel differently about it.

YMMV, of course, and any C programmer needs to be able to understand
the use of strcmp() in a condition (though I confess it takes me a
moment of thought).

[...]

if(foo(bar) == TRUE) /* where true is a macro defined as some non-zero
value */
{
(indented code for the entire rest of the function)
}
return somestatusvariable;

when it should be

if(!foo(bar))
return NONZEROSTATUSVALUE;
(code for the entire rest of the function now not indented so far)

On this I agree wholeheartedly. Never compare a value to TRUE or
FALSE; if such a comparison makes sense, the value is already a
condition and should be used as one.

(note also that some may have different notions as to what TRUE should be
defined as: -1, 1 etc. which makes the test against TRUE not just
idiomatically awkward, but potentially dangerous.)
Yup.

[...]
if(a == b)
{
c = FALSE;
}
else
{
c = TRUE;
}

which should be

c = !(a == b);

Or

c = (a != b);

(Yes, I like the parentheses, even though they're not strictly
necessary.)

[...]

I hope its mindshare is dimishing. I would have written the above as:

if (!cap_issubset(inheritable,
cap_combine(target->cap_inheritable,
current->cap_permitted)))
goto out;

That's indented much too deeply for my taste. Are you using hard tabs
with a non-standard tabstop setting?

I might write:

if (!cap_issubset(inheritable,
cap_combine(target->cap_inheritable,
current->cap_permitted)))
....

This way arguments to functions are lined up.

[snip]

 

[infobahn]

I find that form really annoying

I don't.

and when I see it in others code. It
suggests to me that the person who wrote it doesn't understand boolean
variables and the C idiom that was established with the C standard library.

You are wrong to infer that. I do in fact understand boolean variables.
I also understand that in almost all cases, foo() does not return a
boolean variable, but an int. If foo() is truly boolean in nature,
then I am perfectly prepared to write if(foo(bar)) rather than
if(foo(bar) != 0)

But the fact that you find the form "annoying" suggests that you need to
relax a little.

The idiom I am referring to is that functions should return a value that
answers the question "Did anything go wrong and if so what was it?".

Absolutely. And a boolean variable can only answer one of those
questions, which is why so few of my functions return boolean
variables.

> By that
idiom then it should be obvious to any C programmer worth their pay that

if(strcmp(string1, string2))

means "Did anything go wrong (not match up) when comparing these two
strings?"

No, it should be obvious to any C programmer worth their pay that
the result of strcmp is not boolean, but relational (negative,
zero, or positive).

> (if I wanted to know how far off they were I'd save the return
value to a variable and evaluate that, but rarely does anyone ever care how
far off the comparison was, other functions may have more interesting
non-zero return codes.)

We do, however, care whether the result is negative, zero, or positive.

This form also encourages the early exit from a function:

if(strcmp(string1, string2))
return;

I, however, do not encourage early exit from a function. In all too
many cases, this makes the control flow harder for a maintenance
programmer to follow. Maintenance programmers are often under a lot
of pressure to fix a problem quickly, in code they don't know very
well. Anything we can do to help them out is a bonus, and writing
your functions to have all the structure of spaghetti bolognaise is
not helping anyone.

If you doubt me, look at K&R where you can find numerous examples of this
form and the early exit from functions.

But nobody has to maintain the code in K&R's book. Also, whilst I
greatly admire both K, R, and their book, the day I use K&R as a
style guide is the day I grow an extra arm.

This may seem awkward at first, but you get used to it.

I am fortunate enough not to have got used to early exit from functions.
I am very happy for you if you are used to it, but I have developed my
own style based on my own reasoning and logic, and I'm quite happy to
use that style.

Your style for you; my style for me.

> You should also get
used to writing your own functions in the same idiom, such that they return
zero for success and non-zero (with a value that indicates the level of
failure) for failure. This will preserve the idiom throughout the code.

Oh, I do that already, and have done for many years.

A similar form that is particularly annoying is

if(foo(bar) == TRUE) /* where true is a macro defined as some non-zero
value */

There, I must agree with you. What makes this worse is when foo() is not
a boolean function, and yet its result is still compared against a
"boolean" symbol such as TRUE or FALSE.

{
(indented code for the entire rest of the function)
}
return somestatusvariable;

Oh, I see. You're complaining against code structure.

when it should be

if(!foo(bar))
return NONZEROSTATUSVALUE;
(code for the entire rest of the function now not indented so far)

I prefer:

if(foo(bar))
{
rc = baz();
}
else
{
rc = NONZEROSTATUSVALUE;
}
return rc;

Do you have a problem with the nesting depth here?

(note also that some may have different notions as to what TRUE should be
defined as: -1, 1 etc. which makes the test against TRUE not just
idiomatically awkward, but potentially dangerous.)

Yes, that's what I thought you meant before.

Even worse is

if(a == b)
{
c = TRUE;
}
else
{
c = FALSE;
}

which should be

c = a == b;

This code, whilst correct, will have the newbies (and some older hands)
reaching for their K&Rs. Better: c = (a == b);

or even worse than that

if(a == b)
{
c = FALSE;
}
else
{
c = TRUE;
}

which should be

c = !(a == b);

I would prefer c = (a != b);

Some of you may be laughing at these last two examples, but don't. I've seen
it too many times that it's not funny any more.

I didn't find them particularly funny. Just silly.

I hope its mindshare is dimishing. I would have written the above as:

if (!cap_issubset(inheritable,
cap_combine(target->cap_inheritable,
current->cap_permitted)))
goto out;

Mmmm. Well, just pray you never have to maintain my code.

This way arguments to functions are lined up.

Not in my newsreader, they aren't.

There's no need for any braces
at all,

Well, the compiler doesn't need them. The human sometimes finds them
useful, so I put them in /all/ the time.

so leave them out leaving fewer braces to worry about which ones
match which.

For a start, they should be close enough together that you can
see which ones match which other ones. And even if they aren't,
if you line them up
{
like this
}

you don't have to worry about which ones match which, because it's
obvious. And even if it weren't obvious, decent modern editors can
whizz you from { to } and back in the blinking of an eye.

I do agree with you on that.

Hallelujah, and amen.

 

[E. Robert Tisdale]

I find that form really annoying and when I see it in others code.
It suggests to me that
the person who wrote it doesn't understand boolean variables
and the C idiom that was established with the C standard library.

Idioms are for idiots!

The idiom I am referring to is that functions should return a value that
answers the question, "Did anything go wrong and, if so, what was it?".

That's two questions.

By that idiom then it should be obvious to any C programmer worth their pay that

if (strcmp(string1, string2))

means "Did anything go wrong (not match up) when comparing these two strings?"

Because the result returned by strcmp is not zero
and any non zero result used as a conditional
is [implicitly] converted to true.

(if I wanted to know how far off they were,
I'd save the return value to a variable and evaluate that
but rarely does anyone ever care how far off the comparison was,
other functions may have more interesting non-zero return codes.)

Unfortunately, the rest of us must write code
that is obvious to C programmers *not* worth their pay
as well as C programmers who are worth their pay.
This means that I write explicit code
rather than relying upon implicit conversions.
I would write:

if (0 != strcmp(string1, string2))

to detect strings which don't match.

It isn't my responsibility to ferret out incompetent programmers.
And I don't think that it helps to make competent programmers
work any harder than necessary to understand my intent.

My advice is, "Don't write code
that relies on competent C programmers to maintain it."
Spell it out if it is possible that
some programmer might misinterpret your intent.

 

[Alan Balmer]

the C idiom that was established with the C standard library.
The idiom I am referring to is that functions should return a value that
answers the question "Did anything go wrong and if so what was it?"

But that's just not true, except for the I/O functions. Most others
return some value as a result, not as a diagnostic.

I will write "if (a)" providing 'a' is a boolean. If not, I will write
if (a != 0). If that bothers you, so be it.

 

[Albert van der Horst]

a = (b == c) ? d : e;

a = b==c ? d : e;

Groetjes Albert

 

[Albert van der Horst]

When you've started nesting ?:, though, you've probably gone too far.

pc = 1==x? "one" :
2==x? "two" :
3==x? "three" :
4==x? "five" ;

I find this nesting acceptable, even if it goes on indefinitely.

Gordon L. Burditt

Groetjes Albert

 

[E. Robert Tisdale]

a = b==c ? d : e;

a = (b == c)? d: e;

Is the space before terminators like ? and : a European thing?

 

[Stephen Sprunk]

a = (b == c)? d: e;

Is the space before terminators like ? and : a European thing?

Apparently not, since I do it as well and I'm not European. However, aren't
? and : parts of a ternary _operator_, not _terminators_?

Would you write "a = b+ c;" or "a = b + c;" ? I prefer the latter, and
consider ? and : to be equivalent for formatting purposes.

S

 

[E. Robert Tisdale]

Apparently not, since I do it as well and I'm not European.
However, aren't ? and : parts of a ternary _operator_, not _terminators_?

Would you write "a = b+ c;" or "a = b + c;" ? I prefer the latter,
and consider ? and : to be equivalent for formatting purposes.

Personally, I try to use the same punctuation rules
that are used for ordinary (mathematical) typesetting.
Here are my recommendations:

Terminators always follow immediately after an expression

x@ for all @ in {?, :, ,, ;}

and are followed by at least one white space.
Write

x? y: z

instead of

x ? y : z

or

x?y:z

and write

void f(int, int, int); void g(double);

instead of

void f(int,int,int);void g(double);

for example.

There is no space
between some binary operators and their operands

x@y for all @ in {::, ., ->, .*, ->*, *, /, %, &, ^, |}

but there is always a space
between other binary operators and their operands

x @ y for all @ in {+, -, <<, >>;, <, <=, >, >=, ==, !=,
&&, ||, =, *=, /=, %=, +=, -=, <<=, >>=, &=, |=, ^=}

except when expressions appear as subscripts.
Write

x + y

instead of

x+y
and

x*y

instead of

x * y

for example.
But you may wish to write

A[i+1][j-1]

instead of

A[i + 1][j - 1]

for example to subscript array A.


Most unary prefix operators never have any whitespace
between themselves and their operands

@x for all @ in {::, ++, --, ~, !, -, +, &, *}

but others do

@ x for all @ in {sizeof, new, delete, delete [], throw}

No unary postfix operators

x@ for all @ in {[], (), ++, --}

ever have any whitespace between themselves and their operands.

Use the normal typesetting rules for parentheses (),
square brackets [], angle brackets <> and curly brackets {}.
No space after (, [, < or { and no space before ), ], > or }.
Write

(x)

instead of

( x )

or

(x )

or

( x)

and write

[x]

instead of

[ x ]

or

[x ]

or

[ x]

for example.
There are, of course, exceptions
where extra white space helps to make your code more readable:

double A[2][3] = {{ 1, -1, 0},
{-10, 11, -21}};

 

[Stephen Sprunk]

Personally, I try to use the same punctuation rules
that are used for ordinary (mathematical) typesetting.

Except many operators in C are not ordinary mathematical symbols or may have
non-math meanings in certain contexts.

Here are my recommendations:

Terminators always follow immediately after an expression

x@ for all @ in {?, :, ,, ;}

and are followed by at least one white space.

I agree, except I don't consider ? and : to be terminators -- they're a
ternary operator, which I treat the same as your second group of binary
operators.

There is no space
between some binary operators and their operands

x@y for all @ in {::, ., ->, .*, ->*, *, /, %, &, ^, |}

I'd move the "math" binary operators, *, /, % and the bitwise operators &,
^, | to the following group.

but there is always a space
between other binary operators and their operands

x @ y for all @ in {+, -, <<, >>;, <, <=, >, >=, ==, !=,
&&, ||, =, *=, /=, %=, +=, -=, <<=, >>=, &=, |=, ^=}

except when expressions appear as subscripts.

Or when the use of whitespace decreases readability, common when there are
multiple levels of parens.

Most unary prefix operators never have any whitespace
between themselves and their operands

@x for all @ in {::, ++, --, ~, !, -, +, &, *}

I'd thought a space wasn't legal for these, but my compiler seems to accept
one; it never occurred to me to separate unary operators from their
operands.

but others do

@ x for all @ in {sizeof, new, delete, delete [], throw}

I use the function-like variant of sizeof so I hadn't thought of that; new,
delete, delete[], and throw are not operators in C.

No unary postfix operators

x@ for all @ in {[], (), ++, --}

ever have any whitespace between themselves and their operands.

Use the normal typesetting rules for parentheses (),
square brackets [], angle brackets <> and curly brackets {}.
No space after (, [, < or { and no space before ), ], > or }.

I agree for parens and square brackets, but disagree for angle and curly
brackets. I treat < and > the same as other "math" operators, and I always
put whitespace before/after { and } unless it severely detracts from
readability.

S

 

[Trent Buck]

Up spake Stephen Sprunk:

I'd thought a space wasn't legal for these, but my compiler seems to accept
one; it never occurred to me to separate unary operators from their
operands.

A common parsing technique is to convert text into tokens (discarding
whitespace along the way), then search the sequence of tokens for
patterns. Compilers implemented in this way don't care about
whitespace, only separators between tokens.

An example lexical analyzer might produce the following

"!foo" ==> EXCLAM IDENTIFIER
"! foo" ==> EXCLAM IDENTIFIER
"foo bar" ==> IDENTIFIER IDENTIFIER
"foobar" ==> IDENTIFIER

(C ignores whitespace because the standards says so, but the above might
be considered a `rationale'; in, say, lex+yacc, it's easier to write
that way.)

 

[Christian Bau]

Personally, I don't think of the result of strcmp() as a boolean
value. It's effectively a tri-state value, one of <0, 0, or >0
depending on the result of the comparison. I prefer an explicit
comparison:

if (strcmp(string1, string2) != 0) ...

If the function's name implied that it tests whether the arguments
differ, I might feel differently about it.

First, by definition it is a multi-valued function and not a boolean
function. Second, if it was a boolean function, then the person who
called it "strcmp" and not "strnotequal" should be shot.

 

[Dietmar Schindler]

I use the function-like variant of sizeof ...

There is no function-like variant of sizeof.

 

[Richard Bos]

Apparently not, since I do it as well and I'm not European.

Whereas I don't do it, and I am.

However, aren't ? and : parts of a ternary _operator_, not _terminators_?

Yes, but their use in natural language makes a? b: c more comfortable to
me than a ? b : c.

Richard

 

[Richard Bos]

There is no function-like variant of sizeof.

There's a way to use sizeof that looks as if it's a function call. For
types, it's required. For expressions, it's a consequence of the fact
that (exp) is, to all intents and purposes, the same thing as exp.

Richard

 

[jdallen2000]

The idiom I am referring to is that functions should return a
value that answers the question "Did anything go wrong and
if so what was it?".

Tend to give the function a name that sounds like a predicate; i.e.
isvalid(...) would obviously return true on success; you might
use isntvalid() to cope, but often a *successful* function
won't want to return zero on success -- it will have a story
to tell.

[True Style] is a common style, but its mindshare seems to
be diminishing.

I'll believe you, though it saddens me. Pursuing the analogy
with English, frequent misspellings eventually make their
way into the dictionary, but that doesn't make misspelling
right.

there is no standard for C style

I hope we're not quibbling over a definition of "standard."
The True Style was never universally agreed, of course,
but was in very widespread use among the most elite C
programmers. Good and bad code may be written in any
style of course, but I'm sure there is (was?) a strong
positive correlation between coding in True Style and
positive traits like clarity and modularity. (I'm not
saying True Style is intrinsically conducive to good
coding practice, just that those who use it tend to have
learned from or emulate the Masters.)

Anyway, True Style certainly *was* a standard at Sun Microsystems,
a large company founded by one of the greatest Names in Unix history.
I'd expected any style mandate to be annoying but quickly became
a fan of True Style. Here are my reasons:

(1) I was mostly observing this style already, a major
exception being brace placement. I was writing
}
else
{
but in True Style this is written
} else {
The second form is simply better than the first! The former
form disconnects the keyword "else" from both its antecedent
and postcedent and is distracting to read. Also it wastes
two lines on the screen compared with the latter form, and this
is a "big deal." The left-braces in Non-true code use up
considerable vertical space and therefore more scrolling is
needed to understand a function. Smaller fonts might alleviate
this problem, but that's not an option for those of us
with poor eyesight. (Rarely, I may even run statements
together on the same line, when the statements are *very* similar,
very short, and obviously coupled.)

(2) I was proud to emulate the style of so many Masters.

(3) As I examined various software I noticed the strong correlation
between True Style and good traits like clarity and modularity.
True Style became, in my mind, a badge of honor indicating
that software deserved to be taken seriously. Linus Torvalds
also codes in True Style, so I don't think this is just a
Berkeley/Bell-Labs phenomenon.

(4) Whitespace arrangement isn't all that important but
uniformity would be convenient.
Why did all you apostates insist on deviating anyway?

* * * * * * * * * * * * * * * * *

Although defense counsel continues to recommend `indent'
they offered no rebuttal to this point:

When I nest expressions of (x ? y : z), I tend to use
line-breaks and spacing to make the logic easy-to-see.
Maybe that's why the `indent' fans seemed to disparage
such nesting -- in their environment the helpful spacing
will tend to be expunged!

Are we to conclude that the defendants are satisfied to use
only indent-approved spacing? Who's being dogmatic here, anyway?

* * * * * * * * * * * * * * * * *

15 months ago, in comp.programming about "bracket convention"
I mentioned a stylistic deviation I use, and one of the
defense attorneys in the present case then responded:

Blech.

Let me show this code again, my way and in an "approved style."
(Some of you may not have processed images or other arrays
with multiple homogeneous dimensions, but simple nested for-loops
are a very common idiom in such applications.)

I'm curious if any newsgrouper actually believes the "approved"
coding is more readable here.

My way:
/*
* Do a 3-D convolution.
* Convolve in_sig with conv_k producing out_sig.
* (Delivered code may be slightly different, for performance.)
*/
for (x = in_sig->beg_x; x < in_sig->end_x; x++)
for (y = in_sig->beg_y; y < in_sig->end_y; y++)
for (z = in_sig->beg_z; z < in_sig->end_z; z++) {
val = 0;
for (dx = conv_k->beg_x; dx < conv_k->end_x; dx++)
for (dy = conv_k->beg_y; dy < conv_k->end_y; dy++)
for (dz = conv_k->beg_z; dz < conv_k->end_z; dz++) {
val += in_sig->dat[x+dx][y+dy][z+dz]
* conv_k->dat[dx][dy][dz];
}
out_sig->dat[x][y][z] = val;
}


"Approved" style:
for (x = in_sig->beg_x; x < in_sig->end_x; x++)
{
for (y = in_sig->beg_y; y < in_sig->end_y; y++)
{
for (z = in_sig->beg_z; z < in_sig->end_z; z++)
{
val = 0;
for (dx = conv_k->beg_x; dx < conv_k->end_x; dx++)
{
for (dy = conv_k->beg_y; dy < conv_k->end_y; dy++)
{
for (dz = conv_k->beg_z; dz < conv_k->end_z;
dz++)
{
val += in_sig->dat[x+dx][y+dy][z+dz]
* conv_k->dat[dx][dy][dz];
}
}
}
out_sig->dat[x][y][z] = val;
}
}
}


I understand that many people, including True Stylists, will
deprecate my peculiar for-nesting, especially since the lack of
braces or indentation tends to hide the nesting. FWIW, I *never*
omit the new-line before a for-body, even if it's the trivial
for-body (";"), so (in my private universe) consecutive for's as
above will *always* be nested.

* * * * * * * * * * * * * * * * *

Finally, do let's put the small matter of source code white-space
in perspective. I'll cheerfully denounce True Style if the rest of
you will denounce the insane politics which have mesmerized a
once-great nation.
Best wishes for a Truly Stylish and Happy New Year
James Dow Allen