Another style question
 

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 ) {
...
}
....

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Re: Another style question
 

Christopher Benson-Manica <ataru@nospam.cyberspace.org> scribbled the following:
> 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 (palaste@cc.helsinki.fi) ------------- 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

Re: Another style question
 

Christopher Benson-Manica wrote:

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

Re: Another style question
 

"Christopher Benson-Manica" <ataru@nospam.cyberspace.org> wrote in message
news:bvrh8d$731$1@chessie.cirr.com...
> 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

Re: Another style question
 

Joona I Palaste <palaste@cc.helsinki.fi> spoke thus:

> 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 ;)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Re: Another style question
 

Christopher Benson-Manica wrote:

> 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
<snip>>
> to my preferred style:
<snip>
> 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.

Re: Another style question
 

Peter Pichler <pichlo7@pobox.sk> spoke thus:

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

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Re: Another style question
 

Christopher Benson-Manica <ataru@nospam.cyberspace.org> scribbled the following:
> Joona I Palaste <palaste@cc.helsinki.fi> spoke thus:
>> 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 ;)

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 Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Normal is what everyone else is, and you're not."
- Dr. Tolian Soran

Re: Another style question
 

Ed Morton <morton@lsupcaemnt.com> scribbled the following:
> 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?

--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I am lying."
- Anon

Re: Another style question
 

Joona I Palaste <palaste@cc.helsinki.fi> spoke thus:

> 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
days just reformatting it, never mind fixing actual errors...</ot>

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

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.