What’s a Yoda Condition?
Let’s start this off by explaining what a yoda condition (or notation) is. Yoda conditions are when you do a conditional check (such as an if check) and you swap the constant and the variable around. For example, normally, you would do
length == 5 but a yoda condition would use
5 == length.
Why would anybody want to do that? To avoid human error. You see, in many C-based languages (especially older ones, plus several other languages), places that used conditional expressions (if, while, etc) would allow values that weren’t booleans to be used. Anything that evaluated as 0 was false, and everything else was true (assignments in most languages are expressions that evaluate to the value assigned, rather than expressions).
This could lead to accidentally typing
length = 5, which would always evaluate to true because it would set length equal to 5, which is a truth value. So, in order to avoid such silly mistakes, they would reverse it so the compiler would catch it. Compilers don’t like
5 = length.
Is this still useful? In those languages that still do that, it is, but Java (which is the main language of this blog) is mostly immune. Java only allows boolean expressions as conditionals, so assignments of anything but booleans will not compile. There are a few exceptions though.
If you’re using Boolean objects as opposed to the primitives, and you want to do a null check of that Boolean before your true check involving it (
boolObj == null), then you might have to worry about accidentally setting it equal to null. Luckily, you’ll get a compiler warning about this, but people sometimes ignore warnings when they’re busy. So, either use the yoda condition or pay attention to compiler warnings.
If you want to do an XNOR process (
bool1 == bool2), then there’s a chance of accidental boolean assignment. If both booleans are just boolean variables, then there’s nothing you can do about it, but if one of them is a method call that returns a boolean, you should make that first (
boolMethod() == bool2) so that an error will pop up if you accidentally use a single “
=“, since you can’t assign a value to a value.
Strings are a very interesting case. There is a special yoda condition for that goes like this:
This is such an interesting case because it ignores the need for null checks. It is a shorter, often more optimized (one check as opposed to two), only slightly less readable version of
stringVariable != null && stringVariable.equals("stringLiteral"), since the yoda condition version returns false if
stringVariable is null. Some may argue that it’s more readable, since you can largely ignore the null factor. Seriously, though, this is the most useful yoda condition out there that I’ve seen. Use it; it’s handy.
Some people claim that typical yoda conditions actually provide tiny optimization benefits. While I can’t back up either side, having never looked at the compiled code, I’ve also read that there shouldn’t be any benefits because modern compilers apply the optimization themselves (assuming there is some sort of optimization involved) regardless of which way it’s typed. I just thought I’d get that out there.
Silly Yoda Conditions
Some people take yoda conditions way too far and apply it to comparison operators, such as
!=, etc. This is completely worthless, since there’s no harmful mistake that you’re likely to accidentally make when working with those. They’re extra unhelpful, too, with the fact that it makes it difficult for us to wrap our heads around them. For example,
5 > someVar is so much more difficult to understand than
someVar < 5. Just don’t do these. Ever. Seriously.
So, yeah, that’s my little spiel about yoda conditions. Overall, they’re not that great or useful in smart modern languages, but the String one is really handy. But, if you’re using a different language, you should double-check how it handles these types of situations and whether yoda conditions are useful.