if (expression) check

What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A ?

Personally, I prefer the "if (a == 0)" style - though I know some people
do like the "if (0 == a)" style because it reduces the chances of
assignment (rather than comparison) errors slipping through compilation.
I would explain that rationale to your peer reviewer.

Having said that, IMHO either is fine as long as you are consistent and
clear; without knowing your circumstances, it's hard to say whether your
reviewer has the right to disagree :-)

Steve
--
Stephen Hildrey
Mail: st***@uptime.org.uk / Tel: +442071931337
Jabber: st***@jabber.earth.li / MSN: fo*@hotmail.co.uk

Nov 15 '05 #2

Eric Sosman

ja************@yahoo.com wrote:

What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A ?

style A:
if(0==a)

style B:
if(a==0)

There is no "BIG" difference. People who like A say
it's protection against writing `=' instead of `=='. People
who like B say the mistake can be guarded against in ways
that are less ugly. I'm a B guy, myself, but don't consider
it a "BIG" deal.

As for defending yourself: Watch "Miss Congeniality"
and pay close attention when the protagonist demonstrates
what "SING" means.

--
Er*********@sun.com

Nov 15 '05 #3

Michael Mair

What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A ?
<example snipped down to the essence:> style A:
....
if(0==a)

style B:
....
if(a==0)

The one "real advantage" of style A is that a forgotten second =
leads to a compile time error: 0=a does not compile, whereas a=0
does.
In the presence of compilers and tools like splint that can
warn you about stuff like this, this "advantage" is often
unnecessary. You can find any number of arguments about which
of the two is better in the archives of comp.lang.c. Most people
arguing against it are of the opinion that it is a "less natural"
way of writing the condition.

Personally, I like style B better but put up with A if coding
guidelines, conventions for a project, or similar prefer or
prescribe A.

In the absence of such conventions or standards, this is something
where everyone should be allowed to do as he or she likes --
everything else is mainly bullying of some sort in my eyes.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

Nov 15 '05 #4

Walter Roberson

In article <11**********************@o13g2000cwo.googlegroups .com>,
<ja************@yahoo.com> wrote:

What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A ? style B: if(a==0)

Style A, 0==a, helps reduce problems in which an = is accidently
omitted. If you accidently wrote if(0=a) then the compiler would
complain.

If, though, following Style B you accidently wrote if(a=0)
then the statement is legal but with the undesired side-effect
of setting a to 0. Some compilers will warn about this, but this
is not a requirement and should not be counted on.

The trade-off is that a lot of people find it "unnatural" to
compare a constant to a variable: people tend to think of comparing
a variable to a constant, as in Style B.

There are some variations that might be acceptable, but they require
extra work that might be overlooked: e.g., if((int)a==0)
In this case, if you were to accidently write if((int)a=0)
then the compiler would complain because (int)a is not a modifiable
lvalue. Another form that works: if((a&a)==0) which has the advantage
of not having to know what the type of a is. Or perhaps
if(-a==0) since values do not change their relationship to 0 by
being negated (unless perhaps for an unsigned int on a 1's complement
machine??)
--
Look out, there are llamas!

Nov 15 '05 #5

E. Robert Tisdale

What is the BIG difference
between checking the "if(expression)" in A and B?
I'm used to with style A, "if (0 == a)",
but my peer reviewer likes style B.
How can I defend myself to stay with style A?
Tell your "peer reviewer" to kiss your ....
It's a matter of style.
You don't need to defend it.
style A:
....
....
const int a = 1;
if (0 == a) {
// Don't write my name.
}
....
....

style B:
....
....
const int a = 1;
if (a == 0) {
// Don't write my name.
}
....
....

Nov 15 '05 #6

Mark B

<ja************@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A ?

style A:
....
....
int a = 1;
if(0==a)
{
/* Don't write my name */
}
....
....

style B:
....
....
int a = 1;
if(a==0)
{
/* Don't write my name */
}

I personally prefer style B (not concerned with accidentally
making an assignment as I look at the code when I write it)
but the big defense is: hey, I'm an idiot and style A prevents
me from accidentally making an assignment and thus helps
prevent me from writing buggy code as I can count on the
compiler to catch all of my mistakes! :-)

If your reviewer is truly a peer... tell him that you don't give a
s**t about his personal preferences, style should not be an
issue in a code review. If that doesn't work, refer to the 'big
defense' in the previous paragraph and recite it verbatim.

Hope that helps,
Mark

Nov 15 '05 #7

Mark B wrote:

If your reviewer is truly a peer... tell him that you don't give a
s**t about his personal preferences, style should not be an
issue in a code review. If that doesn't work, refer to the 'big
defense' in the previous paragraph and recite it verbatim.

Around these parts, style is very much part of a peer review.
Programmers are required to write code in a consistent style because in
all likelyhood someone else will end up maintaining the code.

Brian

Nov 15 '05 #8

Christian Bau

In article <11**********************@o13g2000cwo.googlegroups .com>,
ja************@yahoo.com wrote:

What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A ?

style A:
....
....
int a = 1;
if(0==a)
{
/* Don't write my name */
}
....
....

style B:
....
....
int a = 1;
if(a==0)
{
/* Don't write my name */
}
....
....

Try replacing the "==" in "0==a" and "a==0" with a single "=".

The first style must produce an error when you make that change.

The second style with this change is correct C, but will produce a
warning on any C implementation that I would be willing to use. If it
doesn't produce warnings, find out how to turn warnings on in the
compiler. If you can't make the compiler produce a warning, get a
different compiler. If you can't get a different compiler, use style A,
otherwise use style B.

Nov 15 '05 #9

ja************@yahoo.com writes:

What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A ?

style A:
....
....
int a = 1;
if(0==a)
{
/* Don't write my name */
}
....
....

style B:
....
....
int a = 1;
if(a==0)
{
/* Don't write my name */
}
....
....

It is, as you say, a matter of style. That doesn't mean it's trivial,
it merely means that the compiler doesn't care which way you do it --
and the compiler is only one of the many entities that have to look at
your code.

My personal opinion is that the (0==a) form is jarring and ugly. If
it weren't for the possibility of typo-ing "=" rather than "==", there
would be absolutely no reason to use that form; I've never seen
comparisons written like that in languages that don't allow
assignments in expressions. I personally don't consider the risk of
an undetected typo so great that I'm willing to mangle my code like
that. If I really wanted to avoid confusing "=" and "==", I could
define macros ASSIGN and EQUAL_TO, and write a tool that would
complain about any direct use of the operators; the result would be
only slightly uglier than (0==a). (No, <iso646.h> doesn't provide
macros for either "=" or "==".)

But the above is, as I said, only my personal opinion (and a bit
overstated at that). I understand the argument in favor of (0==a),
and I understand that some people don't find it as jarring as I do.
Any competent C programmer should be able to read code using either
form, and any C compiler should generate equivalent (if not identical)
code for both.

Style is a legitimate subject for code reviews. If your work
environment imposes style guidelines that require one form or the
other, you should probably follow those guidelines. If it's a matter
of disagreement between you and a peer, then your opinion is as valid
as his (except, of course, that your peer is right because he agrees
with me).

Ultimately it's probably more of a political question than a language
question. You can expect a lot of opinions here, but I don't think
you can expect much help.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Nov 15 '05 #10

Alex Fraser

<ja************@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A ?

style A: [snip] if(0==a) [snip] style B: [snip] if(a==0)

There is no "BIG" difference IMO. Both are equivalent, and will probably
generate identical code with almost all compilers. That is, this is purely a
style issue.

By proponents of style B, style A is generally considered "less natural"
(and less readable as a result).

The only advantage I have heard for style A is that it prevents "accidental
assignment" (writing '=' instead of '==') because "if (0 = a)" is an error,
whereas "if (a = 0)" is not. In my opinion it is debatable whether this is
actually a significant advantage.

Many compilers and other tools can warn you when an assignment appears but
testing equality seems more likely to be what was intended (such as in the
case above). In cases where assignment *is* intended and the result is a
spurious warning, IMO this is often an indication that it would be clearer
(to a human reader) to write the code differently.

The operands of '==' are often both variables, and in this case accidental
assignment is not an error. If one can learn to avoid accidental assignment
in this case, then there is no more reason for it to occur when one operand
is a constant.

Both these factors erode the advantage of style A; for many people
(including myself), it is reduced to the extent that the disadvantage of
being "less natural" outweighs the advantage.

Alex

Nov 15 '05 #11

Kenneth Brody

What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A ?

style A: [...] if(0==a) [...] style B: [...] if(a==0)

[...]

If you accidentally type "=" instead of "==", style A will generate an
error. Style B may or may not issue an "are you sure?" warning, and will
certainly not generate an error.

Beyond that, the expressions with "==" are functionally identical.

That said, I happen to prefer B.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Nov 15 '05 #12

Kenneth Brody

Default User wrote:

Mark B wrote:
If your reviewer is truly a peer... tell him that you don't give a
s**t about his personal preferences, style should not be an
issue in a code review. If that doesn't work, refer to the 'big
defense' in the previous paragraph and recite it verbatim.

Around these parts, style is very much part of a peer review.
Programmers are required to write code in a consistent style because in
all likelyhood someone else will end up maintaining the code.

"But I _am_ consistent! I always use style B!"

:-)

Yes, I know how style differences make things harder on some people in
a multi-programmer project, but unless TPTB have said "thou shalt use
style A", who's to say which is "right"?

I can always tell who was the last programmer to touch a section of code,
based on the placement of braces and indents.

if ( expr ) {
code;
}

if ( expr )
{
code;
}

if ( expr )
{ code;
}

if ( expr )
{
code;
}

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Nov 15 '05 #13

E. Robert Tisdale

Keith Thompson wrote:

Style is a legitimate subject for code reviews.
If your work environment imposes style guidelines
that require one form or the other,
you should probably follow those guidelines.
If it's a matter of disagreement between you and a peer,
then your opinion is as valid as his (except, of course,
that your peer is right because he agrees with me).

Ultimately,
it's probably more of a political question than a language question.
You can expect a lot of opinions here
but I don't think you can expect much help.

Overly restrictive style guidelines signal gross mismanagement.
They appear to be based upon the mistaken belief that
you can forge a single "super" programmer
out of a diverse group of individuals
by compelling them all to write code the same way -- your way.
This virtually precludes code reuse
because existing codes must be rewritten
to conform with the style guidelines.
Good programmers use style to help them detect mistakes.
Forcing them to use an unfamiliar style increases the likelihood
that they will miss existing bugs and introduce new ones.

Code review is a good idea but the purpose of code review
is, first, to make you a better programmer
and, second, to make your programs better.
Your programming style doesn't matter
as long as you are consistent.
If you are consistent, any competent code reviewer
will quickly adapt to your style and will be able to spot errors
almost as quickly as you can yourself.

Every programmer does *not* need to maintain every code module.
Good managers must be able to exploit specialized skills
and assign modules to the programmers most qualified
to develop and maintain those modules.
Good software engineers must be able to decompose a software package
into independent modules and negotiate well defined interfaces
between those modules so that the programmers assigned to those modules
can work independently of each other.

In other words, good software design should be able to accommodate
various programming styles just as it *must* be able to exploit
various specialized skills.

Nov 15 '05 #14

Kenneth Brody wrote:

Default User wrote:

Mark B wrote:
If your reviewer is truly a peer... tell him that you don't give a
s**t about his personal preferences, style should not be an
issue in a code review. If that doesn't work, refer to the 'big
defense' in the previous paragraph and recite it verbatim.

Around these parts, style is very much part of a peer review.
Programmers are required to write code in a consistent style
because in all likelyhood someone else will end up maintaining the
code.

"But I am consistent! I always use style B!"

:-)

Yes, I know how style differences make things harder on some people in
a multi-programmer project, but unless TPTB have said "thou shalt use
style A", who's to say which is "right"?

That's a problem. In the professional world, being rude to the reviewer
(as has been posted a couple of times) is usually the wrong way to
approach it. The right is to first attempt to resolve it between the
parties, resorting to documention of standard practice if available.
Otherwise, a vote among the reviewers or appeal to a tech lead is the
next step.
Brian

Nov 15 '05 #15

E. Robert Tisdale wrote:

Overly restrictive style guidelines signal gross mismanagement.

As usual, the best idea with ERT advice is to read it and do the
opposite.

Brian

Nov 15 '05 #16

Flash Gordon

E. Robert Tisdale wrote:

Keith Thompson wrote:
Style is a legitimate subject for code reviews.
If your work environment imposes style guidelines
that require one form or the other,
you should probably follow those guidelines.
If it's a matter of disagreement between you and a peer,
then your opinion is as valid as his (except, of course,
that your peer is right because he agrees with me).

Ultimately,
it's probably more of a political question than a language question.
You can expect a lot of opinions here
but I don't think you can expect much help.
Overly restrictive style guidelines signal gross mismanagement.
They appear to be based upon the mistaken belief that
you can forge a single "super" programmer
out of a diverse group of individuals
by compelling them all to write code the same way -- your way.

Nonsense. Style guides are so that anyone familiar with with the style
knows how it will be formatted and can therefore easily scan for certain
things, such as the end of a loop.
This virtually precludes code reuse
because existing codes must be rewritten
to conform with the style guidelines.
Nonsense. I've worked under strict guidelines and reused plenty of code.

Rule 1: Don't reformat just for the hell of it when using third party code.
Rule 2: Don't reformat just for the hell of it if the coding standard
changes.
Rule 3: When modifying code, unless it is a major rewrite follow the
existing style in the module.
Rule 4: Write all new code to the coding standard.
Good programmers use style to help them detect mistakes.
Forcing them to use an unfamiliar style increases the likelihood
that they will miss existing bugs and introduce new ones.
Nonsense. If they are any good they can adapt easily enough. I know
because I have done it and seen others do it.
Code review is a good idea but the purpose of code review
is, first, to make you a better programmer
and, second, to make your programs better.
No, where I worked it was first to determine if the code was fit for
purpose.
Your programming style doesn't matter
as long as you are consistent.
It is easier to review a lot of code from multiple people if they all
use the same style.
If you are consistent, any competent code reviewer
will quickly adapt to your style and will be able to spot errors
almost as quickly as you can yourself.
Why do you think a reviewer can quickly adapt but a programmer can't?

Also, if all the programmers adopt the same style each individual has to
adapt at most once, rather than people having to repeatedly switch
styles as they move between different modules/projects.
Every programmer does *not* need to maintain every code module.
No, but a programmer may need to move on to any of the other modules or
other other projects. Over the years I have often been called on to help
out on other peoples work and having them using the same style makes it
easier to follow.
Good managers must be able to exploit specialized skills
and assign modules to the programmers most qualified
to develop and maintain those modules.
So? If anything that makes it more likely that different developers will
have to look at and work on the code.
Good software engineers must be able to decompose a software package
into independent modules and negotiate well defined interfaces
between those modules so that the programmers assigned to those modules
can work independently of each other.
So?
In other words, good software design should be able to accommodate
various programming styles just as it *must* be able to exploit
various specialized skills.

Exploiting specialised skills does not require using different coding style.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Nov 15 '05 #17

gooch

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:de**********@nntp1.jpl.nasa.gov...

Overly restrictive style guidelines signal gross mismanagement.
They appear to be based upon the mistaken belief that
you can forge a single "super" programmer
out of a diverse group of individuals
by compelling them all to write code the same way -- your way.
Your idea of overly restrictive probably does not coincide with everyone
elses idea of overly restrictive so how do you then say this is too much and
that is not. Someone has to be the person to make the final decision and in
any organization I have ever worked for it was done not only with management
involved but developers as well.

The idea that can't all produce very similar code is nonesense. If every
programmer has to learn every other programmers style you will be wasting
much more time than if every programmer simply learns the standard style.
This virtually precludes code reuse
because existing codes must be rewritten
to conform with the style guidelines.
Good programmers use style to help them detect mistakes.
Forcing them to use an unfamiliar style increases the likelihood
that they will miss existing bugs and introduce new ones.

What are you talking about. Style in no way precludes reuse unless you are
simply not smart enough to make the decision that reused code does not get
altered.
Code review is a good idea but the purpose of code review
is, first, to make you a better programmer
and, second, to make your programs better.
Your programming style doesn't matter
as long as you are consistent.
So you don't think that a reviewers first goal should be to make sure the
code does what it was actually designed to do. I am glad I don't have you on
my team.
If you are consistent, any competent code reviewer
will quickly adapt to your style and will be able to spot errors
almost as quickly as you can yourself.

Just as a good developer can easily adapt to a new style. The difference is
your way the adaptation has to occur multiple times and the other way
everyone only adapts once.
Every programmer does *not* need to maintain every code module.
Good managers must be able to exploit specialized skills
and assign modules to the programmers most qualified
to develop and maintain those modules.
What do you do if there is no longer anyone working on your team that is
familiar with the style used for a particular module. Even worse is how does
the manager keep track of the styles of each module. This is not a solution
it is a nightmare.
Good software engineers must be able to decompose a software package
into independent modules and negotiate well defined interfaces
between those modules so that the programmers assigned to those modules
can work independently of each other.

What the hell does this have to do with having a sensible coding standard?
In other words, good software design should be able to accommodate
various programming styles just as it *must* be able to exploit
various specialized skills.

Interesting conclusion that has nothing to do with having a standard on your
code style. I can't believe you have the nerve to refer to someone who would
be that dead set against a style standard as an engineer. If you would like
to call yourself something coder may be appropriate but you are certainly
not an engineer with that attitude. Every good engineer that ever lived
understands the need for standardization including in stylistic issues. Why
do you think that engineers are taught very early on in their training the
proper way to print (write). Don't you think that other engineers could
eventually decipher their normal chicken scratch, probably so but imposing a
printing standard on engineers ensures they all do it in a similar enough
manner that they can all read.

Nov 15 '05 #18

"gooch" <go******@comcast.net> writes:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:de**********@nntp1.jpl.nasa.gov...
Overly restrictive style guidelines signal gross mismanagement.
They appear to be based upon the mistaken belief that
you can forge a single "super" programmer
out of a diverse group of individuals
by compelling them all to write code the same way -- your way.

Your idea of overly restrictive probably does not coincide with everyone
elses idea of overly restrictive so how do you then say this is too much and
that is not. Someone has to be the person to make the final decision and in
any organization I have ever worked for it was done not only with management
involved but developers as well.

The idea that can't all produce very similar code is nonesense. If every
programmer has to learn every other programmers style you will be wasting
much more time than if every programmer simply learns the standard style.

I recently read a very interesting essay by Ken Arnold, in the Joel
Spolsky's book "The Best Software Writing I". He advocates making
coding style part of the syntax of the programming language. (He's
talking about programming languages in general, not just C.)

For example, if it were decided that if statements should be written
like this:

if (condition) {
...
}

then the following:

if( condition )
{
...
}

would be a syntax error.

Programmers would quickly adapt, simply because they'd have to. You
don't hear complaints about C keywords being in lower case, because if
you try to use "IF" rather than "if" your code won't compile.
Likewise, if your code would no longer compile if you used a
non-standard layout, you'd quickly learn to conform.

The result: Not only would code be more consistent and easier to read,
but we'd stop wasting time arguing about where the braces go.

Drawbacks: None that I can think of (except that it's not likely to
happen in real life).

See also Henry Spencer's 8th Commandment:

Thou shalt make thy program's purpose and structure clear to thy
fellow man by using the One True Brace Style, even if thou likest
it not, for thy creativity is better used in solving problems than
in creating beautiful new impediments to understanding.

<http://www.lysator.liu.se/c/ten-commandments.html>

Perhaps some particular style really is more efficient than the
"standard" one -- but it's vanishingly unlikely that the increase in
efficiency outweighs the countless person-hours wasted arguing about
it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Nov 15 '05 #19

Eric Laberge

Keith Thompson wrote:

"gooch" <go******@comcast.net> writes:
I recently read a very interesting essay by Ken Arnold, in the Joel
Spolsky's book "The Best Software Writing I". He advocates making
coding style part of the syntax of the programming language. (He's
talking about programming languages in general, not just C.) [example] Programmers would quickly adapt, simply because they'd have to. You
don't hear complaints about C keywords being in lower case, because if
you try to use "IF" rather than "if" your code won't compile.
Likewise, if your code would no longer compile if you used a
non-standard layout, you'd quickly learn to conform.

The result: Not only would code be more consistent and easier to read,
but we'd stop wasting time arguing about where the braces go.

[etc.]

I think this is indeed a good idea, but I believe the *computer* should be
in charge of the coding style.

What I have in mind is something like the unix "indent" tool, with more
power/customization/a pretty configuration GUI and integrated in the design
environment or ran stand-alone before the code is uploaded to the revision
control system/repository/whatever and after it is downloaded from it.

This way, every coder can have his own coding style, and it will all look
the same for each other. This seems to me like it would be easy, just a
matter of parsing the code (keeping the comments) and rewriting it using
pre-defined or custom guidelines.

Of course, there would still be the need for comments and code documentation
standards, but this could eliminate style wars like
if (a == 0)
versus
if (0 == a)
or
if (condition) do_stuff();
versus
if (condition)
{
do_stuff();
}

Now feel free to totally crush this idea :^)
--
Eric Laberge

Nov 15 '05 #20

Eric Laberge <de********@myrealbox.com> writes:

Keith Thompson wrote:
"gooch" <go******@comcast.net> writes:
I recently read a very interesting essay by Ken Arnold, in the Joel
Spolsky's book "The Best Software Writing I". He advocates making
coding style part of the syntax of the programming language. (He's
talking about programming languages in general, not just C.)

[example]
Programmers would quickly adapt, simply because they'd have to. You
don't hear complaints about C keywords being in lower case, because if
you try to use "IF" rather than "if" your code won't compile.
Likewise, if your code would no longer compile if you used a
non-standard layout, you'd quickly learn to conform.

The result: Not only would code be more consistent and easier to read,
but we'd stop wasting time arguing about where the braces go.

[etc.]

I think this is indeed a good idea, but I believe the *computer* should be
in charge of the coding style.

What I have in mind is something like the unix "indent" tool, with more
power/customization/a pretty configuration GUI and integrated in the design
environment or ran stand-alone before the code is uploaded to the revision
control system/repository/whatever and after it is downloaded from it.

This way, every coder can have his own coding style, and it will all look
the same for each other. This seems to me like it would be easy, just a
matter of parsing the code (keeping the comments) and rewriting it using
pre-defined or custom guidelines.

Of course, there would still be the need for comments and code documentation
standards, but this could eliminate style wars like
if (a == 0)
versus
if (0 == a)
or
if (condition) do_stuff();
versus
if (condition)
{
do_stuff();
}

Now feel free to totally crush this idea :^)

Ok. 8-)}

Sorry, but if we were to impose style as part of the syntax, I don't
see much benefit in allowing each programmer to write in a different
style. Just define a single style and enforce it. Smart text editors
can help a lot for programmers who want to use them; the programmer
can type his parentheses and braces anywhere he likes, and they'll
*immediately* be put in the right place. Personally, I don't use a
syntax-aware editor (beyond auto-indent); I'll just write the code
correctly in the first place.

This is as much about the programmer's mindset as he's writing the
code as it is about anything else. The point is to end the debate and
spend our time on more important things.

Of course, nobody is going to stop anybody from creating whatever
tools they like, as long as the end result is syntactically correct
source code. But *if* this idea were to catch on, there would be no
more reason to let each programmer have his own coding style than to
let each programmer have his own idea of how reserved words should be
spelled. It's easy enough to create a syntax-aware editor that
transforms "IF" to "if" and "ELSE" to "} else {", but nobody has
bothered to do so.

Surely placement of punctuation marks isn't the best way you can think
of to express your individuality and creativity.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Nov 15 '05 #21

CBFalconer

Keith Thompson wrote:

.... snip ...
See also Henry Spencer's 8th Commandment:

Thou shalt make thy program's purpose and structure clear to thy
fellow man by using the One True Brace Style, even if thou likest
it not, for thy creativity is better used in solving problems than
in creating beautiful new impediments to understanding.

<http://www.lysator.liu.se/c/ten-commandments.html>

Perhaps some particular style really is more efficient than the
"standard" one -- but it's vanishingly unlikely that the increase in
efficiency outweighs the countless person-hours wasted arguing about
it.

At least for C it is worthwhile to keep a standard configuration
for indent available. The following (one line) is the one I use,
which results in something very close to my preferred style with
indent 2.2.9.

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

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

Nov 15 '05 #22

Christian Bau

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

Sorry, but if we were to impose style as part of the syntax, I don't
see much benefit in allowing each programmer to write in a different
style. Just define a single style and enforce it.

On the other hand, your average programmer uses a programming editor
that leaves a few billion operations per second unused, and that is
plenty of time to display code and let me edit code in the style that
_I_ like, and lets you see code and edit code in the style that _you_
like.

Not trivial, but not really difficult either. Probably works best if a
source code control system defines a style X and translates everything
from and to style X when some programmer edits a file.

Nov 15 '05 #23

Richard Bos

Keith Thompson <ks***@mib.org> wrote:

For example, if it were decided that if statements should be written
like this:

if (condition) {
...
}

then the following:

if( condition )
{
...
}

would be a syntax error. The result: Not only would code be more consistent and easier to read,
but we'd stop wasting time arguing about where the braces go.

Drawbacks: None that I can think of (except that it's not likely to
happen in real life).

Drawbacks: see Python.

Richard

Nov 15 '05 #24

gooch wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:de**********@nntp1.jpl.nasa.gov...
[blither blather]
Your idea of overly restrictive probably does not coincide with
everyone elses idea of overly restrictive so how do you then say this
is too much and that is not.

It's useless to try to have a discussion with Trollsdale. He's not
interested in rationally discussing anything, he posts his nonsense to
get a rise out of people. I don't believe for a minute that JPL lets
people program willy-nilly, he's working to a code style guide like
everyone else.

Brian

Nov 15 '05 #25

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Keith Thompson <ks***@mib.org> wrote:
For example, if it were decided that if statements should be written
like this:

if (condition) {
...
}

then the following:

if( condition )
{
...
}

would be a syntax error.

The result: Not only would code be more consistent and easier to read,
but we'd stop wasting time arguing about where the braces go.

Drawbacks: None that I can think of (except that it's not likely to
happen in real life).

Drawbacks: see Python.

Hmm. Point taken. Personally, I like the way Python uses indentation
to denote structure. But I understand that a lot of people don't feel
that way. C, on the other hand, uses braces to denote structure, and
programmers are expected to use braces to communicate to the compiler
*and* indentation to communicate to human readers; great confusion
ensues if they get out of sync.

Anyway, this discussion would probably be more appropriate in
comp.lang.misc.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Nov 15 '05 #26

E. Robert Tisdale

Keith Thompson wrote:

I recently read a very interesting essay by Ken Arnold
in the Joel Spolsky's book "The Best Software Writing I".
He advocates making coding style part of the syntax of the programming language.
That's just plain silly.
(He's talking about programming languages in general, not just C.)

For example,
if it were decided that if statements should be written like this:

if (condition) {
...
}

then the following:

if( condition )
{
...
}

would be a syntax error. cat snippet.cc if( condition )
{
...
}
indent -br snippet.c
cat snippet.c if (condition) {
...}
astyle snippet.c
cat snippet.c

if (condition) {
...
}

Or you could use a code reformatter to convert the code
to your preferred format for easy maintenance
then convert it back into a format
acceptable to your overly picky code reviewer.

There is practically no reason to have or enforce style guidelines.
That's a job for a code reformatter -- not a programmer.
You probably have serious management problems
if you have team members obsessing about coding style.

Allow yourself and the programmers that you work with
to mature and to grow emotionally and intellectually.
Forget about coding style and concentrate on issues
that are really important to good design and engineering.

Nov 15 '05 #27

Malcolm

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote

Allow yourself and the programmers that you work with
to mature and to grow emotionally and intellectually.
Forget about coding style and concentrate on issues
that are really important to good design and engineering.

Communication with the human programmer is really important to good design
and engineering.
Compileable gibberish is asking for bugs.

Nov 15 '05 #28

websnarf

What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A ?

[instead of if(a==0) ... snipped]

Fire the guy that thinks your style is a problem. They have an
extremely weak grasp of elementary algebra and there is a very real
possibility that they are a serious danger to your programming
environment. Obviously your method also has the well known property of
being resistant to the typical single = instead of == typo.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 15 '05 #29

websnarf

Keith Thompson wrote:

"gooch" <go******@comcast.net> writes:
The idea that can't all produce very similar code is nonesense. If every
programmer has to learn every other programmers style you will be wasting
much more time than if every programmer simply learns the standard style.

I recently read a very interesting essay by Ken Arnold, in the Joel
Spolsky's book "The Best Software Writing I". He advocates making
coding style part of the syntax of the programming language. (He's
talking about programming languages in general, not just C.)

This idea comes from the Python programming language, not Joel Spolsky.
I don't know if he acknowledges it, but certainly I do for a lot of
eye opening programming ideas the language has given me (even when
programming in C.)

(It really drives a nail in the coffin of the LISP guys who constantly
claim that other programming languages are really just trying to
emulate things they invented ages ago. Python ain't no Lisp rip off.)

Anyhow, the point is that there is only one style for programming
Python, and the interpretor will not really accept much variation other
than the amount of whitespace.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 15 '05 #30

Flash Gordon

we******@gmail.com wrote:

ja************@yahoo.com wrote:
What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A ?

[instead of if(a==0) ... snipped]

Fire the guy that thinks your style is a problem.

Very unhelpful since most people do not have the option to fire
colleagues, QA engineers working for a different boss, people senior to
then, or anyone else.
They have an
extremely weak grasp of elementary algebra
What makes you think that? If I'm working somewhere where the standard
practice is to express it as
if (variable == test_value)
then at a review I would probably ask for code to be changed to that way
round. I say that as someone who has an above average knowledge of
algebra (based on comparison of my knowledge against the other
developers I have worked with).
and there is a very real
possibility that they are a serious danger to your programming
environment.
Complete nonsense. Or rather, no more try than it is of any other
programmer.
Obviously your method also has the well known property of
being resistant to the typical single = instead of == typo.

Yes, but has been discussed here many times before a number of people
find the
if (test_value == variable)
form jarring and harder to read even though they fully understand that
as far as both maths and C are concerned they have identical meanings.
Even some people who prefer this style (and they are entitled to their
opinion) have accepted that it can take a bit of getting used to.

Personally, I prefer
if (variable == test_value)
I recognise that is personal preference based on what I, personally,
find easier to read. Unless you are able to get inside my mind there is
no reasonable justification you can have for saying I am wrong in my
claim to find it easier to read.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Nov 15 '05 #31

we******@gmail.com writes:

Keith Thompson wrote:
"gooch" <go******@comcast.net> writes:
> The idea that can't all produce very similar code is nonesense. If every
> programmer has to learn every other programmers style you will be wasting
> much more time than if every programmer simply learns the standard style.
I recently read a very interesting essay by Ken Arnold, in the Joel
Spolsky's book "The Best Software Writing I". He advocates making
coding style part of the syntax of the programming language. (He's
talking about programming languages in general, not just C.)

This idea comes from the Python programming language, not Joel Spolsky.
I don't know if he acknowledges it, but certainly I do for a lot of
eye opening programming ideas the language has given me (even when
programming in C.)

The essay was by Ken Arnold, not Joel Spolsky; Joel was the editor of
the book in which it appeared.
Anyhow, the point is that there is only one style for programming
Python, and the interpretor will not really accept much variation other
than the amount of whitespace.

What Ken Arnold advocates goes far beyond what Python does. Python,
compared to, say, C, nails down one minor matter of style: the use of
indentation to denote structure. Everything else in the Python
grammar is as free-form as any other modern language. For example,
the following is legal Python code:

cond=1

if cond:
print "One"
if cond :
print "Two"
if cond:print"Three"

Arnold advocates far stricter rules than that. For example, in C,
this:
if (cond) {
printf("Hello\n");
}
would be valid, but this:
if(cond) {
printf("Hello\n");
}
would be a syntax error. (The only difference is the lack of a space
after the "if" keyword).

You can read the essay at
<http://www.artima.com/weblogs/viewpost.jsp?thread=74230>. Since the
blog has comments enabled, you can also comment on it there -- which
you should do in preference to commenting on it here unless you have a
point that's relevant to C. As I mentioned earlier, comp.lang.misc
would also be a good place to discuss this.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Nov 15 '05 #32

On Sun, 28 Aug 2005 16:48:35 +0100, Flash Gordon
<sp**@flash-gordon.me.uk> wrote:

if (variable == test_value)

wrong; for me it is

if( variable==test_value )
or
if(variable==test_value)

Nov 15 '05 #33

Clark S. Cox III

On 2005-08-29 10:16:12 -0400, cs <n@ss.g> said:

On Sun, 28 Aug 2005 16:48:35 +0100, Flash Gordon
<sp**@flash-gordon.me.uk> wrote:

if (variable == test_value)

wrong; for me it is
if( variable==test_value )
or if(variable==test_value)

What is "wrong" about the quoted line? And how are your two
alternatives any better (or even relevant to the issue being discussed).

--
Clark S. Cox, III
cl*******@gmail.com

Nov 15 '05 #34

akarl

cs wrote:

On Sun, 28 Aug 2005 16:48:35 +0100, Flash Gordon
<sp**@flash-gordon.me.uk> wrote:

if (variable == test_value)

wrong; for me it is

if( variable==test_value )
or
if(variable==test_value)

*plonk*

Nov 15 '05 #35

Charlie Gordon

"cs" <n@ss.g> wrote in message
news:vg********************************@4ax.com...

On Sun, 28 Aug 2005 16:48:35 +0100, Flash Gordon
<sp**@flash-gordon.me.uk> wrote:

if (variable == test_value)

wrong; for me it is

if( variable==test_value )
or
if(variable==test_value)

You are not bold enough to dare use this alternative:

if (variable=\
=test_value)

much faster to read : less eye movement.

--
Chqrlie.

PS: now I have to clean up that vomit on by beloved keyboard.

Nov 15 '05 #36

pete

cs wrote:

On Sun, 28 Aug 2005 16:48:35 +0100, Flash Gordon
<sp**@flash-gordon.me.uk> wrote:
if (variable == test_value)

wrong; for me it is

if( variable==test_value )
or
if(variable==test_value)

Flash Gordon's convention is common
and also the one that I use.

--
pete

Nov 15 '05 #37

On Fri, 09 Sep 2005 11:02:15 GMT, pete <pf*****@mindspring.com> wrote:

cs wrote:

On Sun, 28 Aug 2005 16:48:35 +0100, Flash Gordon
<sp**@flash-gordon.me.uk> wrote:
>if (variable == test_value)

wrong; for me it is

if( variable==test_value )
or
if(variable==test_value)

Flash Gordon's convention is common
and also the one that I use.

it is common, all you and all your bosses use that
but for me it is wrong

Nov 15 '05 #38