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.

Christopher Benson-Manica <ataru@nospam.cyberspace.org> scribbled the following:[color=blue]
> 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[/color]
[color=blue]
> if( cond ) {
> ...
> } else
> if( some_other_cond ) {
> ...
> } else
> if( explode_with_pretty_colors) {
> /* explode with pretty colors */
> }
> else {
> ...
> }[/color]
[color=blue]
> to my preferred style:[/color]
[color=blue]
> if( cond ) {
> ...
> }
> else if( some_other_cond ) {
> ...
> }
> else if( explode_with_pretty_colors ) {
> /* explode! */
> }
> else {
> ...
> }[/color]

Make those if( cond ) thingies if (cond), and you've got my style
pretty much spot-on.
[color=blue]
> Another possibility (I don't use it in C) is[/color]
[color=blue]
> if( cond ) {
> ...
> } else if( blah ) {
> ...
> }
> ...[/color]

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

Joona I Palaste <palaste@cc.helsinki.fi> spoke thus:
[color=blue]
> Make those if( cond ) thingies if (cond), and you've got my style
> pretty much spot-on.[/color]

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.

"Christopher Benson-Manica" <ataru@nospam.cyberspace.org> wrote in message
news:bvrh8d$731$1@chessie.cirr.com...[color=blue]
> How about your if/else if/else constructs? Being nitpicky like any
> good C programmer, I'm in the process of transforming code [...][/color]

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 wrote:
[color=blue]
> 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[/color]

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

Christopher Benson-Manica wrote:
[color=blue]
> 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[/color]
<snip>>[color=blue]
> to my preferred style:[/color]
<snip>[color=blue]
> Another possibility (I don't use it in C) is
>
> if( cond ) {
> ...
> } else if( blah ) {
> ...
> }
> ...
>[/color]

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.

Peter Pichler <pichlo7@pobox.sk> spoke thus:
[color=blue]
> 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.[/color]

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.

Christopher Benson-Manica <ataru@nospam.cyberspace.org> scribbled the following:[color=blue]
> Joona I Palaste <palaste@cc.helsinki.fi> spoke thus:[color=green]
>> Make those if( cond ) thingies if (cond), and you've got my style
>> pretty much spot-on.[/color][/color]
[color=blue]
> That's a house rule. If I were a style Nazi I would have committed
> seppuku my first week ;)[/color]

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

Ed Morton <morton@lsupcaemnt.com> scribbled the following:[color=blue]
> 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.[/color]
[color=blue]
> 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".[/color]

Can the C beautifier also beautify Java?

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

Joona I Palaste <palaste@cc.helsinki.fi> spoke thus:
[color=blue]
> Can you please ask whoever came up with that rule what they were
> smoking? =)[/color]

Will do! :)
[color=blue]
> - Indents are 2 spaces[/color]

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>
[color=blue]
> - Braces K&R style: opening brace on the same line, closing on its own
> line, one space before the opening brace[/color]

I'm a former separate-line'r who's been beaten into submission...
[color=blue]
> - Two blank lines between each function, one blank line separating
> conceptual groups of statements[/color]

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.

Joona I Palaste wrote:
[color=blue]
> Ed Morton <morton@lsupcaemnt.com> scribbled the following:
>[color=green]
>>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.[/color]
>
>[color=green]
>>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".[/color]
>
>
> Can the C beautifier also beautify Java?
>[/color]

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

Ed.

Ed Morton wrote:
[color=blue]
> Joona I Palaste wrote:
>[color=green]
>> Can the C beautifier also beautify Java?[/color]
>
> 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[/color]
[color=blue]
> http://ldp.homegrownhost.net/HOWTO/C...or_others.html[/color]

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.

Joona I Palaste wrote:
[color=blue]
> 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.[/color]

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

--
Thomas.

Thomas Stegen CES2000 wrote:
[color=blue]
> 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.[/color]

And I prefer

a = c * 3 + b;

YMMV.

--
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Christopher Benson-Manica wrote:[color=blue]
> Joona I Palaste <palaste@cc.helsinki.fi> spoke thus:
>[color=green]
> > Make those if( cond ) thingies if (cond), and you've got my style
> > pretty much spot-on.[/color]
>
> That's a house rule. If I were a style Nazi I would have committed
> seppuku my first week ;)[/color]

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.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Joona I Palaste wrote:[color=blue]
>[/color]
.... snip ...[color=blue]
>
> 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.[/color]

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

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

"E. Robert Tisdale" wrote:[color=blue]
> Christopher Benson-Manica wrote:
>[color=green]
> > How about your if/else if/else constructs?
> > Being [anal] like any good C programmer,[/color][/color]
^^^^^^
This is another of Trollsdales gratuitious alterations of quotes.
He is sneaky, very sneaky.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Richard Heathfield wrote:[color=blue]
> Thomas Stegen CES2000 wrote:[color=green]
> > 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.[/color]
>
> And I prefer
>
> a = c * 3 + b;
>
> YMMV.[/color]

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.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

CBFalconer <cbfalconer@yahoo.com> spoke thus:
[color=blue]
> So, which is the house rule?[/color]

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

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

CBFalconer <cbfalconer@yahoo.com> scribbled the following:[color=blue]
> "E. Robert Tisdale" wrote:[color=green]
>> Christopher Benson-Manica wrote:[color=darkred]
>> > How about your if/else if/else constructs?
>> > Being [anal] like any good C programmer,[/color][/color]
> ^^^^^^
> This is another of Trollsdales gratuitious alterations of quotes.
> He is sneaky, very sneaky.[/color]

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

--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I will never display my bum in public again."
- Homer Simpson

Joona I Palaste <palaste@cc.helsinki.fi> spoke thus:
[color=blue]
> Christopher originally wrote "nitpicky", not "anal". It's fun to see
> what Trollsdale will alter *my* message to. =)[/color]

Well, in this case at least it's fairly benign - one might call it
un-euphemizing my choice of words ;)

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

Christopher Benson-Manica wrote:
[color=blue]
> How about your if/else if/else constructs?[/color]

if (cond) { /* brace can be here... */
/* ... */
}
else
if (cond) /* ...or line below... */
{ /* (depending on what looks best at the time) */
/* ... */
}
else /* ...but never after final else */
{
/* ... */
}

--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|

In <bvrj10$ofn$1@oravannahka.helsinki.fi> Joona I Palaste <palaste@cc.helsinki.fi> writes:
[color=blue]
>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:[/color]

Which means that you've never been involved in some open/free source
code collaboration, where the ability to produce and read *meaningful*
diffs is essential. Any stylistical changes to the code are a major
source of "noise" and the rest of the collaboration would promptly
kick you out.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

In <40218B88.B917A066@yahoo.com> CBFalconer <cbfalconer@yahoo.com> writes:
[color=blue]
>Richard Heathfield wrote:[color=green]
>> Thomas Stegen CES2000 wrote:[color=darkred]
>> > 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.[/color]
>>
>> And I prefer
>>
>> a = c * 3 + b;
>>
>> YMMV.[/color]
>
>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.[/color]

As a beginner, I would not insert any space that was not required by the
language. A habit inherited from FORTRAN programming on punched cards,
where you really wanted to avoid continuation cards. Then, one day I was
bitten by

i=-1;

being parsed as

i =- 1;

by a VAX C compiler (=- was the anachronic form of -=, but some
pre-ANSI compilers still supported it). After that, I always left one
space between operators and operands, just to be on the safe side. This
kind of bugs (the compiler parses the code differently than the human) is
just too difficult to spot, so it pays the "effort" needed to avoid it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

Dan Pop <Dan.Pop@cern.ch> scribbled the following:[color=blue]
> In <bvrj10$ofn$1@oravannahka.helsinki.fi> Joona I Palaste <palaste@cc.helsinki.fi> writes:[color=green]
>>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:[/color][/color]
[color=blue]
> Which means that you've never been involved in some open/free source
> code collaboration, where the ability to produce and read *meaningful*
> diffs is essential. Any stylistical changes to the code are a major
> source of "noise" and the rest of the collaboration would promptly
> kick you out.[/color]

You guessed right. The only "real" programming I've ever done is for
university exercises and an actual commercial job. With both of these,
a change that does nothing else than make the code more readable is
accepted.

--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The truth is out there, man! Way out there!"
- Professor Ashfield

On 5 Feb 2004 18:02:56 GMT, in comp.lang.c , Joona I Palaste
<palaste@cc.helsinki.fi> wrote:
[color=blue]
>Dan Pop <Dan.Pop@cern.ch> scribbled the following:[color=green]
>> In <bvrj10$ofn$1@oravannahka.helsinki.fi> Joona I Palaste <palaste@cc.helsinki.fi> writes:[color=darkred]
>>>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:[/color][/color]
>[color=green]
>> Which means that you've never been involved in some open/free source
>> code collaboration, where the ability to produce and read *meaningful*
>> diffs is essential. Any stylistical changes to the code are a major
>> source of "noise" and the rest of the collaboration would promptly
>> kick you out.[/color]
>
>You guessed right. The only "real" programming I've ever done is for
>university exercises and an actual commercial job. With both of these,
>a change that does nothing else than make the code more readable is
>accepted.[/color]

Its also worth noting that any code diff or version control tool that
takes meaningless whitespace into account should be abandoned. It
should always be possible to beautify dense code without aggravation.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Mark McIntyre <markmcintyre@spamcop.net> spoke thus:
[color=blue]
> Its also worth noting that any code diff or version control tool that
> takes meaningless whitespace into account should be abandoned. It
> should always be possible to beautify dense code without aggravation.[/color]

Believe me, if it were in my power to use something other than
Microsoft's Visual Sourcesafe at my employment docimile, I certainly
would.

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

In <bvu0gg$7gj$1@oravannahka.helsinki.fi> Joona I Palaste <palaste@cc.helsinki.fi> writes:
[color=blue]
>You guessed right. The only "real" programming I've ever done is for
>university exercises and an actual commercial job. With both of these,
>a change that does nothing else than make the code more readable is
>accepted.[/color]

Keep in mind that readability is in the eye of the beholder. What's
more readable to you may be less readable to the person who wrote the
code in the first place. We had plenty of threads proving this, in this
very newsgroup.

The only consensus is that some form of indentation is better than
no indentation at all and that identifiers with meaningful names are
better than identifiers of the form oo0o00oo and l111ll1ll.

But once we start comparing the merits of different kinds of indentations
or identifier naming conventions, the Pandora's box is open...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

On Fri, 6 Feb 2004 02:18:06 +0000 (UTC), in comp.lang.c , Christopher
Benson-Manica <ataru@nospam.cyberspace.org> wrote:
[color=blue]
>Mark McIntyre <markmcintyre@spamcop.net> spoke thus:
>[color=green]
>> Its also worth noting that any code diff or version control tool that
>> takes meaningless whitespace into account should be abandoned. It
>> should always be possible to beautify dense code without aggravation.[/color]
>
>Believe me, if it were in my power to use something other than
>Microsoft's Visual Sourcesafe at my employment docimile, I certainly
>would.[/color]

the vesion of vss that I last used actually had an option to ignore
whitespace. STR that it didn't actually work as such tho....
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Dan Pop wrote:[color=blue]
>
> In <bvu0gg$7gj$1@oravannahka.helsinki.fi> Joona I Palaste <palaste@cc.helsinki.fi> writes:
>[color=green]
> >You guessed right. The only "real" programming I've ever done is for
> >university exercises and an actual commercial job. With both of these,
> >a change that does nothing else than make the code more readable is
> >accepted.[/color]
>
> Keep in mind that readability is in the eye of the beholder. What's
> more readable to you may be less readable to the person who wrote the
> code in the first place. We had plenty of threads proving this, in this
> very newsgroup.
>
> The only consensus is that some form of indentation is better than
> no indentation at all and that identifiers with meaningful names are
> better than identifiers of the form oo0o00oo and l111ll1ll.
>
> But once we start comparing the merits of different kinds of indentations
> or identifier naming conventions, the Pandora's box is open...
>
> Dan
> --
> Dan Pop
> DESY Zeuthen, RZ group
> Email: Dan.Pop@ifh.de[/color]

I think it's possible to develop reasonably objective, nonrandom
standards of readbility. But some things done in the name of readability
fly in the face of prohibitions against early return, some formatting
conventions.

--
Les Cargill

Les Cargill wrote:
[color=blue]
> I think it's possible to develop
> reasonably objective, nonrandom standards of readability.[/color]

I think that it's possible to develop several of them.

Take a look at the indent man page:

http://www.cs.umbc.edu/cgi-bin/man-cgi?indent

Look for the COMMON STYLES header.
[color=blue]
> But some things done in the name of readability
> fly in the face of prohibitions against early return,
> some formatting conventions.[/color]

You probably need to distinguish
between *coding* styles and *programming* styles.

Coding styles are adequately handled by a program like indent
which will reformat your code for you.
Any attempt to impose a particular coding style is pure mischief.
You should develop or adopt a coding style and -- stick to it!
Consistency is most important in your coding style.
It will help you spot mistakes.
If other programmers need to read, understand and maintain your code,
they will quickly become accustomed to your style
or they will reformat it with indent.

Programming style, on the other hand, is something much more serious.
It's about nothing less than good programming practice --
developing good programming habits and avoiding bad programming habits.
For C programmers, it's about [self]discipline.
Good C programmers try to get their compiler to detect bugs for them.
They also include assertions to help them trap bugs at run time.
They use const to make their code easier for other programmers
to analyze. They avoid global and static variables.
They pass by value or const reference so that other programmers
need not be concerned about whether or not a function call modifies
its actual arguments. etc.

"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote in message news:<40215839.3000006@jpl.nasa.gov>...[color=blue]
> Ed Morton wrote:
>[color=green]
> > Joona I Palaste wrote:
> >[color=darkred]
> >> Can the C beautifier also beautify Java?[/color]
> >
> > 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[/color]
>[color=green]
> > http://ldp.homegrownhost.net/HOWTO/C...or_others.html[/color]
>
> 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.[/color]

Ok, how about gnu indent - is it to be trusted?

Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

re: Another style question

Similar C / C++ bytes

/bytes/development

/bytes/it

/bytes/about