aspose file tools*
The moose likes Java in General and the fly likes if (x != null) vs in (null != x) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "if (x != null) vs in (null != x)" Watch "if (x != null) vs in (null != x)" New topic
Author

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

Steve H
Greenhorn

Joined: Jul 11, 2002
Posts: 1
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

Joined: Jan 30, 2000
Posts: 18671
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.


"I'm not back." - Bill Harding, Twister
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
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

Joined: Jun 10, 2002
Posts: 30
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

Joined: Mar 06, 2001
Posts: 1209
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

Joined: Jan 07, 1999
Posts: 6920
And don't get too confident. Java hasn't entirely eliminated the "missing '='" problem. Try the following:


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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

Joined: Jun 27, 2002
Posts: 4118
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


Java Regular Expressions
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112

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 ]

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Jan 07, 1999
Posts: 6920
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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Jan 07, 1999
Posts: 6920
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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Jan 07, 1999
Posts: 6920
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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Jan 07, 1999
Posts: 6920
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: if (x != null) vs in (null != x)
 
Similar Threads
Garbage Collector
Garbage Collector question
Grains - algorithm
difference between null string and ""
Array quiz I can't solve