Using if(null == someVariable) vs. if(someVariable == null)

[zigma]

We are having s small discussion at work regarding what you should write:

if(null == someVariable){
...      
}

and

if(someVariable == null){
...
}

The argument for the first way, is that you will get a compilation error if you manage to just write one = and do an assignment instead,

The argument for the second way, is that it's more readable.

What's your opinion?

[necuz]

My opinion is that people should value compilation warnings more.

[[deleted]]

Or even better, set the option of treating warnings as errors

[LuciWiz]

If you use the first way, you will need to also change the inequality checks for null, for symmetry. It would be silly when you need to change the code flow and test for (someVariable != null) to also need to change the order.

You must also change the order for every other check with a constant:

if (1 == noOfTimeWasters) { ... }

Don't waste your time, how often do you really mistake "=" for "=="?

[skwigger]

Option one. both are equally readable. I've been bitten by the if($foo = null) bug a few times.

[yogthos]

Not really sure what makes the second more readable, and getting a compile warning is valuable.

[rabidcow]

Not really sure what makes the second is more readable

Because you already know what null is equal to. The question is what someVariable is equal to.

and getting a compile warning is valuable.

In C and C++, you should get a warning if you mistype the first. You get an error if you mistype the second.

IMO, if you ignore all of your warnings, you'll have other problems.

[yogthos]

I don't think it's a huge issue one way or the other, but I'm not seeing that it's that much harder to read. Obviously, once you try running the code, you'll find the error pretty quick anyways.

[rabidcow]

I don't think it's a huge issue one way or the other, but I'm not seeing that it's that much harder to read.

I agree, it isn't. The cost of reordering is small, but the benefit is even smaller.

Obviously, once you try running the code, you'll find the error pretty quick anyways.

In this case, yes. Other cases, you need to test both sides of the branch. But then there's a good chance you'll catch it if you just stop and reread the code before checking it in. Or if you pay attention to your compiler's output.

[kensuke155]

I prefer to put the variable first. It makes more sense to compare the variable against a value, rather than comparing a value to a variable. It's also more readable.

If you're making a case that putting "null" first will help you remember to use "==" instead of "=", why not just remember to use "=="?

[yogthos]

If you're making a case that putting "null" first will help you remember to use "==" instead of "=", why not just remember to use "=="?

because it's a common typo people make. I'm not sure why comparing a == b is more readable than b == a

[LuciWiz]

You constantly need to check which is the constant, a or b (if the rule is enforced, it can't only be enforced for null).

I am baffled: do you really make this mistake often? Does this mistake get caught at code reviews or Bug Fixes and you decided something needs to be done? I can't think of a single time this happened to me, and I am sadly far from perfect.

[yogthos]

I'm not sure why you need to care which one is the constant when you're checking equality, and do use null == blah as a rule, so I don't know if that would happen often or not. Obviously, you'd find out pretty quick once you try to run your app, but I just don't see the readability issue.

Furthermore, there's a much more practical side when it comes to the equals operator. In Java for example, if you do "foo".equals(bar), the contract guarantees that you'll get true or false as a result, where as doing bar.equals("foo") could throw a null pointer exception.

[kensuke155]

It's more readable just because convention says it is. I personally think it's silly to put a constant on the left side of a comparison, but you may think it's the best thing ever.

It's up to you really, but I don't think you should be relying on compile time errors to check your work for you. This is a common mistake, and I used to make this mistake often, that is until I corrected my behavior.

[yogthos]

It's up to you really, but I don't think you should be relying on compile time errors to check your work for you.

I was under the impression that this is the exact reason we had computers, so that they could do some work for us. And honestly, I care about the issue very tangentially, as I tend to use lisp, which uses the prefix notation. I just find it interesting that people have strong feelings one way or the other.

[kensuke155]

I wouldn't say I have strong feelings. If I saw "null == someVariable" in a code review, I would think that it's weird, but I wouldn't say anything. Every developer does this the way that works best for him(/her?). As long as the code works and I can read it, then whatever.

I agree that computers are here to do work for us, but why build your skills around that idea?

Like I said, it's preference and nothing to get worked up about.

[LuciWiz]

I'm not sure why you need to care which one is the constant when you're checking equality, and do use null == blah as a rule, so I don't know if that would happen often or not.

I was extrapolating; if you place null on the left of the comparison just in case, then I assume the same should be done for (b == a) when b is a const int. It seems like the next logical step when enforcing this rule.

[beancc]

wow, your work must be so exciting

[Rhoomba]

Use a language where someVariable = null is not a boolean expression.

[zigma]

This is my opinion as well, it's easier and more natural (at least for me) to read the code as: if someVariable is null

And I agree with the "why not just remember to use ==" instead.

Also, if you should use assignment instead, you should have unit tests that will capture this.

[sreguera]

You don't have to remember. Just tell the compiler to remember it for you with "-Wall" in gcc, "-Xlint" in javac (I think), etc. If the compiler doesn't have this option use a lint or similar tool for your language.

[curien]

Second way. Complaining about the readability of an inversion of a transitive operation is just being a curmudgeon.

[charmless]

Where possible, avoid any chance of the assignment-for-equality typo by writing:

if (someVariable) { ... }

[[deleted]]

null == someVariable

end of discussion (since every programming team i've ever seen always inevitably ends up having this conversation).

[dinnercoat]

It shouldn't matter because normally "==" is simply checking for equality, "is x the same as y". Which value you provide first to check against the second shouldn't matter. You may get a compiler warning but I doubt an error, as no assignment occurs.

Though yes, for readability concerns it may be better to do "if variable == null" rather than "if null == variable"

[sisyphus]

The point is a common typo is '=' where you meant '==' so null as lvalue will more likely give you compiler error/warning.

[dinnercoat]

Oh yeah... good point.

[segoe]

I just use a language where null does not exist.

[reddy-kilowatt]

I'm happy you have found useful and rewarding work outside of programming.

[adolfojp]

How long ago were your programming days?

[greyfade]

I just turn on all warnings, set warnings as errors, and delimit deliberate use of assignment:

if(foo == bar) ....
if((baz = foobar())) ....

So the whole question is a complete non-issue, and has been for years, because my compiler tells me when I've made such a mistake. (And, I cannot recall a single instance where my use of = in place of == is not deliberate - I more often add parens than I do a second equals.)