String.equals() argument ordering

Question

I recently received a downvote for using the following in a recent answer:

String word = ...;
if (\"s\".equals(word) || \"y\".equals(word)

Answer 1

There is a special case pf Yoda conditional I've not seen defended, or attacked, in any of the answers, so I'll add it for reference. This is the style of:

 if(0 < x && x <= max) {

A Yoda conditional because the constant (0) is before the variable (x). The argument against Yoda conditionals is that is hinders readability. Contrast that example with the functionally equivalent

 if(x <= max && x > 0) {

Do you really think that, non-Yoda variant, is more readable? I don't.

For readability when using ordering relational operators (<, <=, >, >=), I prefer the style of these heuristics:

• Use consistent ordering relations: > is consistent with >=, but not with < or <=; < is consistent with <=.
• Prefer < and <= to > and >=, as the default is ascending order.
• Place conditions that impose a lower bound on the variable before conditions that impose an upper bound, if using < and <=. Do the opposite if using > and >=.

This very often produces a Yoda conditional for the lower bound.

Answer 2

Bill Pugh asked this question at Devoxx 2011. The vast majority of people went for the form "xyz".equals(str). I am with Bill, now preferring str.equals("xyz").

It's fundamental to the Java tradition that we find errors as early as reasonably possible. NPEs are exceptionally common. We want to route these nulls out as soon as possible.

If you're expecting the reference to maybe null, then I don't particularly object to the backwards notation. It's nice to be explicit and easier to understand that there may be a null with a separate null check, but the reverse order should be well understood and sufficiently differentiate the code from the normal case where null is forbidden.

Working in security, some of the bugs null-tolerance accommodates are vulnerabilities.

Answer 3

TL;DR; This definitely is poor coding style NOT :D

well, the yoda conditions are useful in languages where non-boolean can evaluate to a boolean value, e.g.

int test = 0;
if ( test ){ /* do something */

but this is not allowed in Java so you don't run into problems such as forgetting '=', e.g.

if ( test = 2 ){ /* do something */

instead of test == 2

• the compiler will not let you do this. So the yoda condition may seem unnatural to someone who has not had to care about this (because he/she didn't use any other language but Java).

This definitely is NOT poor coding style it is just not very common to see Java code using it

Answer 4

yoda condition is where oup put the literal in front of the variable.

word.equals("s") is read as "word equals s"

"s".equals(word) a human reads as "s equals word"

Our brains read the first example much better and the code is clearer.

the only reason imho to use yoda conditions is to prevent assignment as in "if (42 = i)" instead of "if(42 == i)"

Answer 5

Visit the following link to understand what is meant by Yoda Conditions|Notation

Its not a "poor coding style" its diferent way of coding.

Yoda can be usefull to track typos in some languages, i believe the -1 was not deserved to be honest but that is my personal opinion.

But Yoda can be bad as explained in this lengthy but very interesting article.

End of the day, there are supporters in favor and against this kinda of notation.

Answer 6

One might argue that you should (unit-)test your code enough to be confident that nulls don't go where they're not supposed to. This should obviate the need for yoda conditions.