if (expression) check

[jamilur_rahman]

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

 

[Stephen Hildrey]

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

 

[Eric Sosman]

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.

 

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

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

 

[Walter Roberson]

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

 

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

 

[Mark B]

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

 

[Default User]

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

 

[Christian Bau]

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.

 

[Keith Thompson]

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.

 

[Alex Fraser]

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

 

[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:[email protected]>

 

[Kenneth Brody]

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:[email protected]>

 

[E. Robert Tisdale]

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.

 

[Default User]

"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

 

[Default User]

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

 

[Flash Gordon]

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.

 

[gooch]

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.

 

[Keith Thompson]

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.

 

[Eric Laberge]

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 :^)