Another style question

[Christopher Benson-Manica]

How about your if/else if/else constructs? Being nitpicky like any
good C programmer, I'm in the process of transforming code written
like

if( cond ) {
...
} else
if( some_other_cond ) {
...
} else
if( explode_with_pretty_colors) {
/* explode with pretty colors */
}
else {
...
}

to my preferred style:

if( cond ) {
...
}
else if( some_other_cond ) {
...
}
else if( explode_with_pretty_colors ) {
/* explode! */
}
else {
...
}

Another possibility (I don't use it in C) is

if( cond ) {
...
} else if( blah ) {
...
}
....

 

[Joona I Palaste]

How about your if/else if/else constructs? Being nitpicky like any
good C programmer, I'm in the process of transforming code written
like

if( cond ) {
...
} else
if( some_other_cond ) {
...
} else
if( explode_with_pretty_colors) {
/* explode with pretty colors */
}
else {
...
}

to my preferred style:

if( cond ) {
...
}
else if( some_other_cond ) {
...
}
else if( explode_with_pretty_colors ) {
/* explode! */
}
else {
...
}

Make those if( cond ) thingies if (cond), and you've got my style
pretty much spot-on.

Another possibility (I don't use it in C) is

if( cond ) {
...
} else if( blah ) {
...
}
...

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"'So called' means: 'There is a long explanation for this, but I have no
time to explain it here.'"
- JIPsoft

 

[E. Robert Tisdale]

How about your if/else if/else constructs?
Being [anal] like any good C programmer,
I'm in the process of transforming code written like

[snip]

I prefer:

if (cond) {
...
}
else
if (some_other_cond) {
...
}
else
if(explode_with_pretty_colors) {
/* explode with pretty colors */
}
else {
...
}

But like I said
Get a C reformatter program like indent:

http://www.gnu.org/software/indent/indent.html

so that you can convert
from one format to another automatically.

 

[Peter Pichler]

How about your if/else if/else constructs? Being nitpicky like any
good C programmer, I'm in the process of transforming code [...]

Why do you need to transform code from one style to another? If you use
any source-control system, it may lead to too many differences that aren't.

FWIW, my prefered style is similar to yours, except that I use:

if (cond)
{
...
}
else if (some_other_cond)
{
...
}
else
{
...
}

The opening brace sits on its own line, just like the closing one, and the
two indent the same. There is a space before the opening parenthesis and
voluntary space after the closing one, but never the other way round. Now,
this is The Only True Style, so stick to it!

Peter

 

[Christopher Benson-Manica]

Make those if( cond ) thingies if (cond), and you've got my style
pretty much spot-on.

That's a house rule. If I were a style Nazi I would have committed
seppuku my first week

 

[Ed Morton]

How about your if/else if/else constructs? Being nitpicky like any
good C programmer, I'm in the process of transforming code written
like

to my preferred style:

Another possibility (I don't use it in C) is

if( cond ) {
...
} else if( blah ) {
...
}
...

If you're going for consistency, why not just run all your code through
a C beautifier and just accept whatever it spits out? As long as all the
code's consistent in style, the actual style selected doesn't matter a
whole lot.

FWIW the UNIX tool "cb -s" (K&R mode) spits out your boss's preferred
style for case statements and the final style above for if...else.
Without the "-s" it still prefers your boss's case style but doesn't
appear to do anything useful with "if...else".

Ed.

 

[Christopher Benson-Manica]

Why do you need to transform code from one style to another? If you use
any source-control system, it may lead to too many differences that aren't.

Well, there is that, of course, but I figure that since MY style is
the "One Style," it's justified. One style to rule them all...

 

[Joona I Palaste]

That's a house rule. If I were a style Nazi I would have committed
seppuku my first week

Can you please ask whoever came up with that rule what they were
smoking? =)

Personally I'm a bit of a style Nazi myself. Whenever I have to edit
code someone else wrote, I take time to format it to "readable" style
first. Which means:
- Indents are 2 spaces
- Braces K&R style: opening brace on the same line, closing on its own
line, one space before the opening brace
- Always 1 space after every comma and every semicolon, otherwise
1 space around every "important" operator or no spaces at all if it's
not "important"
- Always 1 space between *keywords* (if, for, while, etc) and the
opening paren, never any space between a function or a macro name and
the opening paren
- Two blank lines between each function, one blank line separating
conceptual groups of statements
That's pretty much the important stuff.

 

[Joona I Palaste]

If you're going for consistency, why not just run all your code through
a C beautifier and just accept whatever it spits out? As long as all the
code's consistent in style, the actual style selected doesn't matter a
whole lot.

FWIW the UNIX tool "cb -s" (K&R mode) spits out your boss's preferred
style for case statements and the final style above for if...else.
Without the "-s" it still prefers your boss's case style but doesn't
appear to do anything useful with "if...else".

Can the C beautifier also beautify Java?

 

[Christopher Benson-Manica]

Can you please ask whoever came up with that rule what they were
smoking? =)

Will do!

- Indents are 2 spaces

Ours are five. I count on the pain to wake me up on Monday morning.
It isn't as bad as our <ot>HTML, however - indentation is essentially
random, making editing tables and scripts a joy. I've spent several

- Braces K&R style: opening brace on the same line, closing on its own
line, one space before the opening brace

I'm a former separate-line'r who's been beaten into submission...

- Two blank lines between each function, one blank line separating
conceptual groups of statements

That's another bad thing - there is space between initial declarations
and code, but blank lines elsewhere within functions are frowned upon.
Heavens knows why...

 

[Ed Morton]

Can the C beautifier also beautify Java?

Maybe, but I wouldn't trust cb with Java or even C++. There are plenty
of beautifiers for those and other languages out there though, e.g. take
a look at
http://ldp.homegrownhost.net/HOWTO/C-C++Beautifier-HOWTO/beautifier_for_others.html

Ed.

 

[E. Robert Tisdale]

Maybe, but I wouldn't trust cb with Java or even C++.
There are plenty of beautifiers
for those and other languages out there though, e.g. take a look at

http://ldp.homegrownhost.net/HOWTO/C-C++Beautifier-HOWTO/beautifier_for_others.html

BEWARE!

Code "beautifiers" are not necessarily [style] reformatters.
Most beautifiers insert text and embedded printer control sequences
that your compiler will *not* accept.

You also need to verify that
reformatting did not change the meaning of your code.
Always compile both the original and the reformatted versions
of your code and verify that the resulting objects are identical.

 

[Thomas Stegen CES2000]

Can you please ask whoever came up with that rule what they were
smoking? =)

Personally I'm a bit of a style Nazi myself. Whenever I have to edit
code someone else wrote, I take time to format it to "readable" style
first. Which means:
- Indents are 2 spaces
- Braces K&R style: opening brace on the same line, closing on its own
line, one space before the opening brace
- Always 1 space after every comma and every semicolon, otherwise
1 space around every "important" operator or no spaces at all if it's
not "important"
- Always 1 space between *keywords* (if, for, while, etc) and the
opening paren, never any space between a function or a macro name and
the opening paren
- Two blank lines between each function, one blank line separating
conceptual groups of statements
That's pretty much the important stuff.

Say what you will, but the above are not very important elements in
determining whether a style is good or bad. Some are more important
than other. I would say spaces around most operators is a good thing.

But in general, as long as layout style is consistent and somewhat
reasonable, naming and commenting conventions are more important.
As are conventions for when to use and not to use macros.

If you find code much harder to read because the opening brace of
a block is on its own line instead of K&R style, then it is not
the code that has a problem.

1. while(condition) {
condition = important();
}

2. while ( condition )
{
condition = important();
}

Point is, 1 vs 2 should be hardly an issue. If you are someone who uses
1 and must work for some people who demand 2 then I don't see that you
have a problem at all.

I use neither of the above, but if someone gave me some reason for why
I should use 1 or 2 I would not have a problem doing that.

I think I would object if someone told me to code like this though:
a=b+c*3;
I think a = b + c * 3; is much better. There is even a physiological
reason for this. I think it is called crowding. It basically means that
human eyes have an easier time distuinguishing objects which are further
apart than close together. So there, I have a non-emotional,
non-subjective reason for this particular style choice. Which means I
win

 

[Richard Heathfield]

Joona I Palaste wrote:

I think I would object if someone told me to code like this though:
a=b+c*3;
I think a = b + c * 3; is much better.

And I prefer

a = c * 3 + b;

YMMV.

 

[CBFalconer]

That's a house rule. If I were a style Nazi I would have committed
seppuku my first week

My argument is that if is not a function, and thus should have a
following blank. If you want blanks surrounding "cond" be my
guest. I want to easily distinguish function calls from other
constructs. Richard Heathfield disagrees.

So, which is the house rule?

BTW, a useful style rule is that the else clause is the longer
one, other things being equal. This makes finding the controlling
statements easier. Contrast:

if (foo) {
....
....
}
else {
/* notmuch */
bar();
}

with
if (notfoo) {
/* notmuch */
bar();
}
else {
....
....
}

finding a controlling statment for something in the else clause
involves first finding the else, and then continuing north. The
second phase is much easier with the short then clause. In the
extreme, when applied to else if clauses, you get:

if (foo) foof();
else if (bar) barf();
else if (goo) goof();
else {
moo();
gou();
gai();
pan();
}

All of this is all very well when you are developing your style.
However once you have something, be consistent, at least through
any single source file. Try things out and see what minimizes the
errors and maximizes the readability.

 

[CBFalconer]

.... snip ...

Personally I'm a bit of a style Nazi myself. Whenever I have to edit
code someone else wrote, I take time to format it to "readable" style
first. Which means:
- Indents are 2 spaces
- Braces K&R style: opening brace on the same line, closing on its
own line, one space before the opening brace
- Always 1 space after every comma and every semicolon, otherwise
1 space around every "important" operator or no spaces at all if
it's not "important"
- Always 1 space between *keywords* (if, for, while, etc) and the
opening paren, never any space between a function or a macro name
and the opening paren
- Two blank lines between each function, one blank line separating
conceptual groups of statements
That's pretty much the important stuff.

I think we are pretty close to agreement. Try the following for
indent.pro. It is not perfect, but comes as close as I have found
possible to my style.

-kr -l66 -i3 -bad -di16 -lc66 -nce -ncs -cbi0 -bbo -pmt -psl -ts1

 

[CBFalconer]

How about your if/else if/else constructs?
Being [anal] like any good C programmer,

^^^^^^
This is another of Trollsdales gratuitious alterations of quotes.
He is sneaky, very sneaky.

 

[CBFalconer]

And I prefer

a = c * 3 + b;

YMMV.

Definitely MV. I can even find cases where I want different
emphasis, and would write:

a = 3*c + b;
or
dsq = b*b - 4*a*c;

although normally I would not suppress the blanks.

 

[Christopher Benson-Manica]

So, which is the house rule?

Both - the if( and the ( cond ). Our editor even auto-formats like
this.

 

[Joona I Palaste]

How about your if/else if/else constructs?
Being [anal] like any good C programmer,

^^^^^^
This is another of Trollsdales gratuitious alterations of quotes.
He is sneaky, very sneaky.

Christopher originally wrote "nitpicky", not "anal". It's fun to see
what Trollsdale will alter *my* message to. =)