when using equals method with a null string...

[Chris Uppal]

It is regrettable that courses often show »&&« only in the
context of »if«, so that beginners are lead to assume that
»&&« can only occur in this context.

Arguably teachers should also go out of their way to show comparison operators
like == and < outside the condition part of "if" and "while" statements.

I've seen code like:
if (a < b)
doSomething(true);
else
doSomething(false);
which (IMO) clearly indicates a flawed understanding.

-- chris

 

[Roedy Green]

No, Java order of evaluation is always left to right (JLS 15.7).
Order of evaluation has nothing to do with precedence and
associativity.

In what order are these casts applied:

byte b = (byte) (int) 343.3D;

 

[Oliver Wong]

Arguably teachers should also go out of their way to show comparison
operators
like == and < outside the condition part of "if" and "while" statements.

I've seen code like:
if (a < b)
doSomething(true);
else
doSomething(false);
which (IMO) clearly indicates a flawed understanding.

Sometimes the code used to say something else (i.e. the "then" branch
and the "else" branch were both complex, and very different), then someone
used an automated refactoring tool, and eventually the changes were such
that the code ended up looking like the above. Since the programmer was
using a tool, rather than refactoring by hand, (s)he (and the tool) might
have not noticed that the above could be further simplified, especially if
several thousands of other refactorings were done in the same session.

I've done this for example; leaving behind "stupid" code after a massive
refactoring session, I mean.

- Oliver

 

[Chris Uppal]

Oliver Wong wrote:

[me:]

Sometimes the code used to say something else (i.e. the "then" branch
and the "else" branch were both complex, and very different), then someone
used an automated refactoring tool, and eventually the changes were such
that the code ended up looking like the above.

I suppose that is a plausible sequence.

I wouldn't be any too happy if it actually occurred, though. Not in code that
/I/ had to work with...

Since the programmer was
using a tool, rather than refactoring by hand, (s)he (and the tool) might
have not noticed that the above could be further simplified, especially if
several thousands of other refactorings were done in the same session.

FWIW, I have very little time for automated refactoring tools.

-- chris

 

[Roedy Green]

FWIW, I have very little time for automated refactoring tools.

I think the key is to see them as tools you invoke when you want a
certain refactoring rapidly and accurately done, rather than
mindlessly accepting whatever "recommendations" the tool makes.

 

[Lasse Reichstein Nielsen]

In what order are these casts applied:

byte b = (byte) (int) 343.3D;

Inside out!

An expression is evaluated by evaluating each sub-expression, from
left to right, and then combining the results. Since casts are unary
prefix operators, there is only one sub-expression, so this holds
trivially.

Precedence and associativity does not affect order of evaluation, but
structure of the parse tree (i.e., which sub-expressions exist).

/L

 

[Roedy Green]

Inside out!

the (int) is evaluated before the (byte). If you ask a 5 year old,
they will tell you that is right to left.

 

[Lasse Reichstein Nielsen]

the (int) is evaluated before the (byte). If you ask a 5 year old,
they will tell you that is right to left.

More precisely: "(int) 343.3D" is evaluated (to the value 343) before
"(byte) 343" is evaluated.

Or, the order of evaluation is:

byte b = (byte) (int) 343.3D;
------------ first
------------------- second
----------------------------- last
The part that is evaluated grows towards the left, but it's not
"right before left".
Compare that to an expression like:

foo() - bar() - baz()
----- first
----- second
------------- third
----- fourth
--------------------- fifth
In all cases, sub-expressions of the same expressions are evaluated
left before right. I.e., evaluating as a post-order left-to-right
depth-first traversal of the syntax tree.

/L

 

[Guest]

Also note that when you want to compare a String with a constant
string, instead of doing:
if (input != null && input.equals("secret")) doSomething();
you can do:
if ("secret".equals(input)) doSomething();

Mike