Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

if (x != null) vs in (null != x)

 
Steve H
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can anybody tell me if there is any difference between the following statements:
1) if (x != null) ...
2) if (null != x) ...
My normal coding method is to use 1) as it tends to read easier, but I have seen examples of 2).
Any advantages/disadvantages either way ?
Thanks
Steve
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The only difference is that as you noted, the former is more readable for most people. The other form makes some sense in other languages like C/C++, but not in Java really.
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
this is what i understand..
int x = 10;
if (x = 10){
}
is valid in C/C++ i guess and the test will always pass. But this is more of a typo,
probably the developer did'nt mean to do that.
So C/C++ developers probabyl prefer
if (10 == x){
}
since writing
if(10 = x){
} --> will result in a compile time error in any language and they can probabyl avoid such bugs.

But that's not a problem in java (since it will be a compile time error in both cases).
in java if() s'd result in a boolean condition and (x=10) does'nt result in a boolean and will fail. Looks like Java intentionally eliminated this issue.
Originally posted by Steve Hirth:
Can anybody tell me if there is any difference between the following statements:
1) if (x != null) ...
2) if (null != x) ...
My normal coding method is to use 1) as it tends to read easier, but I have seen examples of 2).
Any advantages/disadvantages either way ?
Thanks
Steve
 
Michael Zalewski
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think it makes a difference.
But it is better to do it backwards if you are comparing a string.

is better than

because the first one does not blow up if myString is null.
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yeah ! i just realized that c/c++ does'nt have any problems with regards to relational operators.

Originally posted by Michael Zalewski:
I don't think it makes a difference.
But it is better to do it backwards if you are comparing a string.

is better than

because the first one does not blow up if myString is null.
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And don't get too confident. Java hasn't entirely eliminated the "missing '='" problem. Try the following:
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah. The last is why I wrote "but not in Java really" rather than "but it's completely useless in Java". There are a few cases where this technique could be of benefit in Java, but it's rare, and I find the readability issue more important. On the other hand I do often reverse the order of String comparisons as Karthik suggests, if it's a context where a null string is an allowed possibility. If null is not supposed to be allowed anyway, I will keep the "normal" order to force a NullPointerException and detect an error immediately rather than hiding it. I suppose now that 1.4 is out it would be nicer/clearer to put
assert variable != null;
at the beginning of a method to get this effect.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Steve Hirth:
Any advantages/disadvantages either way ?
QUOTE]

It's just a coding convention designed to make sure that you don't accidently reasign variables. Not sure, but I think they suggest it in "The Elements of Java Style". Personally, I'm not abig fan of it.
HTH,
M
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

OTOH, using something like

is bad style anyway - you should instead write

or probably even

[ July 13, 2002: Message edited by: Ilja Preuss ]
[ July 13, 2002: Message edited by: Ilja Preuss ]
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja wrote: OTOH, using something like ... is bad style anyway - you should instead write ...
I know, I know, but that was just a simple example. What happens if the "false" is repaced by a parameter and x is a member variable? You might never know that this has happened until much later on. And it is quite likely to not have been caught by unit tests, either. Who thinks to check every "if" for side-effects?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Frank Carver:
[QB]Ilja wrote: OTOH, using something like ... is bad style anyway - you should instead write ...
I know, I know, but that was just a simple example. What happens if the "false" is repaced by a parameter and x is a member variable?

Mhh, yes - I didn't thought of that case. Interestingly, I can't remember to ever have needed to do something like that...
And it is quite likely to not have been caught by unit tests, either. Who thinks to check every "if" for side-effects?

I don't think I understand this question. Why do you think you have to explicitely test for the side-effect? Either the new if-statement breaks already existing functionality (which should let a test fail), or it doesn't (so it doesn't do any harm). Am I missing something?
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem with the unit tests is that (say, in my example of a member variable being unexpectedly updated as a side effect) this is unlikely to be unit tested at the time the code is created. On the principle of "only test things you think might break", I can't think of anyone paranoid enough to test the entire system state after every "if".
So what happens is that several (many?) changes later someone writes some code which happens to depend on the value of the member variable. And gets wierd test failures. The usual rule is that in a well unit-tested system, (almost) all test failures are as a result of a fault in the new code, so a lot of effort will probably be spent battling with code which works when tested separately on a hand-crafted test fixture, but not when used together.
This is especially hard because it is an "integration" style of fault, but is most likely to show up when the developers are not in an "integration" mindset, but instead focussing on small areas of code.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Frank Carver:
The problem with the unit tests is that (say, in my example of a member variable being unexpectedly updated as a side effect) this is unlikely to be unit tested at the time the code is created. On the principle of "only test things you think might break", I can't think of anyone paranoid enough to test the entire system state after every "if".

Well, that might mean that it doesn't happen often enough to be paranoid about it...
That doesn't mean that these things don't happen - I just recently encountered a similar problem. The only adequate thing I know to do about it is to further strengthen my position on the value of pair programming...
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja wrote: Well, that might mean that it doesn't happen often enough to be paranoid about it
Maybe. But t's also one of those things about Java that "everyone knows" - you can't get an accidental side effect from an "if" like you can in C/C++. We've seen the surprised posts in this very thread.
It is an unfortunate downside of the development of the Java language being hype-driven.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Frank Carver:
It is an unfortunate downside of the development of the Java language being hype-driven.

I am not sure I do understand you here. Are you referring to how the language was developed or how it is seen by most developers - or something entirely different?
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How it was developed, really. Initially (back when it was still OAK) Java was designd to "scratch someone's itch". Then it was noticed at Sun, and got fed into the hype machine. Pretty much all future language enhancements and advertsing were market-led rather than technically led.
The initial focus on Applets was a typical example. I had to spend a lot of time explaining patiently that Java was not just about bouncing heads and scrolling news tickers on a browser window.
Glossing over reality for the sake of marketing copy is another problem which has haunted it since inception. "Write Once Run Anywhere", "You never need to worry about memory usage", " = and == can never be confused", etc. etc. The kind of things that we end up answering again and again here at the Ranch.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Frank Carver:
How it was developed, really. Initially (back when it was still OAK) Java was designd to "scratch someone's itch". Then it was noticed at Sun, and got fed into the hype machine. Pretty much all future language enhancements and advertsing were market-led rather than technically led.
The initial focus on Applets was a typical example. I had to spend a lot of time explaining patiently that Java was not just about bouncing heads and scrolling news tickers on a browser window.
Glossing over reality for the sake of marketing copy is another problem which has haunted it since inception. "Write Once Run Anywhere", "You never need to worry about memory usage", " = and == can never be confused", etc. etc. The kind of things that we end up answering again and again here at the Ranch.

Isn't this more a problem of marketing than one of language design? Or do you think the language itself suffered, too?
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's hard to tell with the language itself, but there have been several well-known "cock ups" in the standard APIs.
Some things I long for are still not part of the language (relative imports, for example) and the standard APIs (a Tree or TreeNode interface in the java.util Collections API, for example), but I don't expect my views to have more weight than anyone else's.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic