tags:

views:

429

answers:

7

Hi all,

I noticed for a while now the following syntax in some of our code:

if( NULL == var){
   //...
}

or

if( 0 == var){
  //...
}

and similar things.

Can someone please explain why did the person who wrote this choose this notation? (instead of the common var == 0 way)

Is it a matter of style, or does it somehow affect performance?

+4  A: 

To avoid the

if (var = NULL)

bug

jpoh
Really ? wow I would have never guessed this one ... tnx
Roman M
+13  A: 

It's a mechanism to avoid mistakes like this:

if ( var = NULL ) {
  // ...
}

If you write it with the variable name on the right hand side the compiler will be able catch certain mistakes:

if ( NULL = var ) {  // not legal, won't compile
  // ...
}

Of course this won't work if variable names appear on both sides of the equal sign and some people find this style unappealing.

Edit:

As Evan mentioned in the comments, any decent compiler will warn you about this if you enable warnings, for example, gcc -Wall will give you the following:

warning: suggest parentheses around assignment used as truth value

You should always enable warnings on your compiler, it is the cheapest way to find errors.

Lastly, as Mike B points out, this is a matter of style and doesn't affect the performance of the program.

Robert Gamble
Most compilers worth their salt will give you a warning for the first example.
Evan
Yep, as I just commented in the question my compiler has always caught this for me, I'll update the answer.
Robert Gamble
Not only should you enable warnings on the compiler - you should pay attention to them, and revise the code so that the warnings cease to appear. Otherwise, you end up with builds with thousands of warnings...which are a complete pain. (I work on one such - it infuriates me!)
Jonathan Leffler
And when I say 'revise the code', I don't just mean 'insert random casts until the warnings cease', which is a common misinterpretation of how to fix a lot of compiler warnings.
Jonathan Leffler
+1  A: 

Quoting Joel On Software, The Guerrilla Guide to Interviewing:

Occasionally, you will see a C programmer write something like if (0==strlen(x)), putting the constant on the left hand side of the == . This is a really good sign. It means that they were stung once too many times by confusing = and == and have forced themselves to learn a new habit to avoid that trap.

(I'm not really a fan of this "best practice".)

Federico Ramponi
hehe, (0 == strlen(x)) is actually a bad sign, ('\0' == x[0]) would be good :)
quinmars
+3  A: 

If you mistakenly put

if ( var = NULL )

instead of

if ( var == NULL )

then there will only be a compiler warning. If you reverse the order:

if ( NULL == var )

then there will be a compiler error if you put

if ( NULL = var )

Personally, I hate to read code written that way, and I only made that mistake once in my first year of coding. =)

Kieveli
This is why my students are required to compile with -Wall -Werror. So I don't have to read the ugly stuff :-)
Norman Ramsey
+1  A: 

Just by the way, I've observed over many years teaching C to new programmers that if you train yourself to read "=" as "gets" and "==" as equals, that in itself will save you from a lot of these bugs. Then you read

if( x = 0){

as "if x gets 0 then" and that begins to sound weird.

Charlie Martin
That is a good idea only if you're never going to read any mathematics in your life again :p
ShreevatsaR
If I'm being careful in explaining code to somebody else, I tend to use "is assigned" for =.
Greg Hewgill
Shree, you do this all the time if you're moving from math to computers, and even in math. Consider saying when we say T(n)=O(n) -- that "=" isn't an "equals", it's an abuse of the notation to say it is. Calling the "=" symbol "gets" just acknowledges this.
Charlie Martin
+1  A: 

Personally, I prefer

if (!x) {

That works fine for checking against zero but not so much for any other value.
Robert Gamble
It's also just a little too easy to miss the ! when looking over someone elses code...
Mr.Ree
+1  A: 

Corollary: try to use const as much as you can.

const int val = 42;

if (val = 43) {
    ...
}

will not compile.

Ates Goral
I'm all for using const wherever possible but you don't usually check the value of constant variables nearly as often as you do variables that actually change so I don't know how much this would really help. The easiest way to avoid these kinds of errors is to enable compiler warnings.
Robert Gamble
another idea is to do if(+val = 43) and even if val is non-const, it still won't compile :)
Johannes Schaub - litb
@litb: That's an interesting idea but it will only work for arithmetic types (not pointers).
Robert Gamble
Robert, these are the darn diffs between C and C++ :/ in C++ +ptr is possible and yields an rvalue.
Johannes Schaub - litb
I didn't know about that difference between C and C++ - cheers :-)
James Hopkin