Boolean question

gerarda

Hi all,
Just trying to get my head around why "Fish for dinner" is printed when the boolean status is set to false.

public class dinner {
public static void main (String args[]){

boolean isKeeperFish = false;
if(isKeeperFish = true){
System.out.println("Fish for dinner");
}
else{
System.out.println("Take out for dinner");
}
}
}

10-10-20

If you try "if(isKeeperFish = false){" does it change the result or not?

im...LOST

Not 100% sure because I'm much more of a as3 guy but don't you need to use == instead of just a single = when comparing?

so this might work?

if(isKeeperFish == true)

gerarda

10-10-20 wrote: »

If you try "if(isKeeperFish = false){" does it change the result or not?

Yes, it changes the output:

Take out for dinner

DonkeyStyle \o/

im...LOST wrote: »

Not 100% sure because I'm much more of a as3 guy but don't you need to use == instead of just a single = when comparing?

^ This

Also you should be able to use them directly as true/false statements without having to actually compare them to true or false:

if(isKeeperFish) { //true}
and
if(!isKeeperFish) { //false }

Makes everything nice and readable if your variable names make sense.
Also might shed some light on why the assignment operator (=) isn't working the way you expect.

stesh

DonkeyStyle \o/ wrote: »

^ This

Also you should be able to use them directly as true/false statements without having to actually compare them to true or false:

if(isKeeperFish) { //true}
and
if(!isKeeperFish) { //false }

Makes everything nice and readable if your variable names make sense.
Also might shed some light on why the assignment operator (=) isn't working the way you expect.

The reason "Fish for dinner" is being printed is that on line 5 you write:

if(isKeeperFish = true){

'=' is the assignment operator; it assigns the value 'true' to the variable 'isKeeperFish'. '==' is the comparison operator.

Malice

Well spotted Stesh!

I don't have a Java IDE to hand to check this out on but you could probably shorten your lines by doing the checks like this instead which would eliminate problems with the equals sign:

[PHP]if (isKeeperFish){
// Do stuff.
}[/PHP]

or
[PHP]if (!isKeeperFish){
// Do other stuff.
}[/PHP]

Galtee

Or, if you wanted to keep the boolean keyword 'true' in the statement then get into the habit of writing the boolean keyword first as below

if (true==isKeeperFish)

this way if you forget an equals and have

if (true=isKeeperFish)

you'll get a complie time error as true cannot be assigned to.

Colonel Panic

That is something I got into the habit of going over the past few months.

Malice

Galtee wrote: »

if (true=isKeeperFish)

While I can see the benefit of the compile-time error capability if that method is used I must admit I find it quite hard to read. I also use ReSharper which will catch and flag typos like that automatically .

Galtee

Malice wrote: »

While I can see the benefit of the compile-time error capability if that method is used I must admit I find it quite hard to read. I also use ReSharper which will catch and flag typos like that automatically .

I don't like using 3rd party tools for detecting these anomolies. I like to try and keep things as pure as possible

amen

I don't like using 3rd party tools for detecting these anomolies. I like to try and keep things as pure as possible

+1. Don't be depending on 3rd part tools to catch your mistakes.

ChRoMe

amen wrote: »

+1. Don't be depending on 3rd part tools to catch your mistakes.

It shouldn't make you sloppy but using static code analysis are very beneficial tools. Even the best make stupid mistakes, nature of the beast.

Malice

Just to clarify, I wasn't recommending to rely on the likes of ReSharper to catch errors like that, I just happened to have VS2010 open in another window while browsing this thread the other day so I was curious if it would catch it since it catches quite a lot of other code constructs that could be improved. I still think my approach from this post beats writing the statement backwards.

ChRoMe

Malice wrote: »

Just to clarify, I wasn't recommending to rely on the likes of ReSharper to catch errors like that, I just happened to have VS2010 open in another window while browsing this thread the other day so I was curious if it would catch it since it catches quite a lot of other code constructs that could be improved. I still think my approach from this post beats writing the statement backwards.

Agreed, anything that produces easier to read code is a good thing.

Procasinator

I agree with Malice here. The variable itself is named appropriately so iisKeeperFish or !isKeeperFish reads better to me than isKeeperFish == true or isKeeperFish == false, or flipping the operands. It's as much value as saying if ((x < y) == true) - it's obvious we are working with a boolean in the left, so why do we need the right at all?

I suppose if the variable or method call wasn't obviously boolean, then I might use == true/false. I don't think I'd put the literal first though as I find it less skimmable.

Galtee

personally I use the If (isKeeperFish) syntax myself but doesn't really matter to me which way I read it, ie if sifting through someone elses code I wouldn't change it for the sake of it but that's just me.

Galtee

short interlude

boolean, boolean, boolean, boolean
Im begging of you please don't take my man
boolean, boolean, boolean, boolean
Please don't take him just because you can
Your beauty is beyond compare
With flaming locks of auburn hair
With ivory skin and eyes of emerald green
Your smile is like a breath of spring
Your voice is soft like summer rain
And I cannot compete with you, boolean:D

The_B_Man

I usually go with the if (boolean) method as well but when I'm doing other stuff like checking for null, over the summer I've started flipping them like if (null==someObject).

AFAIk, this is how it should be done when reading in command line args,eg:

public void main(String [COLOR="Magenta"]arg0[/COLOR])
{
if ([COLOR="Magenta"]arg0[/COLOR] == [COLOR="RoyalBlue"]someConstant[/COLOR])
{//do stuff}
}

But if "arg0" is null, then it'll be trying to evaluate a null value, and will give a runtime error I think.
So, if you go:

public void main(String arg0)
{
if ([COLOR="RoyalBlue"]someConstant[/COLOR] == [COLOR="Magenta"]arg0[/COLOR])
{//do stuff}
}

then this will just evaluate if its equal to "someConstant" and if its null, then thats fine.

tehjimmeh

The_B_Man wrote: »

I usually go with the if (boolean) method as well but when I'm doing other stuff like checking for null, over the summer I've started flipping them like if (null==someObject).

What's the point of that? The null pointer in Java (and I assume you're talking about Java, since in C++ you could just write "if (someObject)" ) isn't a valid boolean value. "if (someObject = null)" will not compile.

The_B_Man

"someObject" was not meant as a boolean. It could be anything like a database connection or a string.

Flipping them has to do with the compiler evaluating the object on the left and then just checking if the one on the right is equal, without evaluating it.

I think theres also some security issuie where someone could provide an object with some stack overflow trickery in it. If its on the left, it will be evaluated and the malicious code can be run, but if its on the right, it'll only be compared. Thats just from my newb knowledge though so dont quote me.

tehjimmeh

The_B_Man wrote: »

"someObject" was not meant as a boolean. It could be anything like a database connection or a string.

I am aware of what you meant by "someObject".

"someObject == null", however, is a boolean value.
"someObject = null" evaluates to null, which is not a boolean value, therefore "if(someObject = null)" will not compile, meaning it's pointless to write "if(null == someObject)" to get the compiler to catch an error if you mistakenly type =.

The_B_Man wrote: »

Flipping them has to do with the compiler evaluating the object on the left and then just checking if the one on the right is equal, without evaluating it.

I think you're either confused or my understanding of Java is lacking. Could you explain what you mean by "evaluation the object on the left" here?

AFAIK, == for objects in Java is a reference comparison. No "evaluation" happens, it just checks if the references are to the same object.

The only time I can think of when some kind of evaluation happens is if you use == to compare a boxed primitive (Integer, Double, Float etc.) against an ordinary primitive (int, double, float etc.). In this case, you can get a NullPointerException if the boxed primitive is null, because it attempts to extract it's value to compare against the ordinary primitive's value, and it contains none.

This stackoverflow thread explains this quite well.

I don't really understand why flipping operands in == would make sense in your command line args example...

EDIT: Reading back over your command line args example, it's making even less sense. Is that even a valid main method?

ChRoMe

tehjimmeh wrote: »

EDIT: Reading back over your command line args example, it's making even less sense. Is that even a valid main method?

Its not an array being passed and it isint static, so no.

Procasinator

The_B_Man wrote: »

But if "arg0" is null, then it'll be trying to evaluate a null value, and will give a runtime error I think.
So, if you go:

I think you have one thing in your head and trying to apply to it other areas where it not needed. It seems like you are talking about something like this:

if (person != null && person.Name = "The_B_Man") {
    // Blah
}

If person is null, we could not check that person.Name value (as we'd get a runtime error).

Other than that, I can't see what you could be trying to accomplish or prevent in your code examples.

croo

Perhaps what the The_B_Man is thinking about is something Joshua Bloch mentions in his excellent book "Effective Java".

He suggests that you should always override the equals in a object, so when you compare the object it compares not on the object reference but the data within that makes it unique.

So to use the examples here, you could check is

person.equals("The_B_Man")

But then if person was null you'd get an exception because a null will have no equals method.

So the practise is to write the comparison as

"The_B_Man".equals(person)

The equals() method would trap the null so even if person is null there is no problem. This is a less problematic approach and considered best practise on projects I've worked on.

But that approach is for objects... for primitives like boolean it doesn't apply.

Malice

So...did gerarda get his question answered?

tehjimmeh

croo wrote: »

Perhaps what the The_B_Man is thinking about is something Joshua Bloch mentions in his excellent book "Effective Java".

He suggests that you should always override the equals in a object, so when you compare the object it compares not on the object reference but the data within that makes it unique.

So to use the examples here, you could check is

person.equals("The_B_Man")

But then if person was null you'd get an exception because a null will have no equals method.

So the practise is to write the comparison as

"The_B_Man".equals(person)

The equals() method would trap the null so even if person is null there is no problem. This is a less problematic approach and considered best practise on projects I've worked on.

But that approach is for objects... for primitives like boolean it doesn't apply.

I was thinking he meant something like that, but then thought "this isn't C#, you can't override == in Java...".