Another style question

[Christopher Benson-Manica]

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

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

 

[Programmer Dude]

How about your if/else if/else constructs?

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 */
{
/* ... */
}

 

[Dan Pop]

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:

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]

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.

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

 

[Joona I Palaste]

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.

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.

 

[Mark McIntyre]

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.

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.

 

[Christopher Benson-Manica]

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.

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

 

[Dan Pop]

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.

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

 

[Mark McIntyre]

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

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

 

[Les Cargill]

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

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.

 

[E. Robert Tisdale]

I think it's possible to develop
reasonably objective, nonrandom standards of readability.

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.

But some things done in the name of readability
fly in the face of prohibitions against early return,
some formatting conventions.

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.

 

[Rob Somers]

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.

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

 

[E. Robert Tisdale]

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

No.

But I must admit that I often use it without bothering
to check the emitted code for consistency.

Also, I always modify indent to format my C code
exactly the way I want it.
I probably shouldn't trust my modified version as much as I do
but the C compiler catches most of the mistakes right away
and I have been able to fix the bugs without much trouble.
So far, I haven't had any real problems with it.