I first encountered Yoda conditions when a co-worker used them for “safe” null checks. I asked him why he did it that way and he told me that it helps him avoid accidental assignment.

A “Yoda condition” is when you swap the operands so that the one that doesn’t get assigned is on the left. So if you’re testing whether a variable equals a certain value, instead of putting the variable on the left, the comparison operator in the middle, and the value on the right, you do the opposite. You put the value on the left, the comparison operator in the middle (as usual), and the variable on the right.

The entire purpose of this exercise is to avoid accidental assignments, such as using = instead of == as your operator (going from a comparison operator to an assignment operator.)

// An example of a Yoda condition
if (null == $data) { /* ... */ }

// Accidental assignment
if ($data = null) { /* ... */ }

In this case, by swapping the operands and accidentally using an assignment operator, your compiler or interpreter will error out because a value cannot be assigned another value or variable.

For example, null cannot be assigned $data, or in the example below, 123 cannot be assigned the value $input.

if (123 = $input) {
  // Oops, we accidentally tried to assign something!
}

(Too much cognitive load for my tastes.)

Yoda’s Possible Origins (Not That Yoda)

There may be an origin story to Yoda conditionals. Older C/C++ compilers didn’t have the testing support that more recent and modern ones do today. Apparently at some point, these compilers evolved and eventually did detect these types of conditions, of which they could be spat out as warnings or errors at compile time.

Here’s Why They Shouldn’t Be Used

So why shouldn’t you use them?

I suppose unnecessary cognitive load may be subjective in this case, but it seems a bit excessive to go through this operand dance to avoid accidental assignment. Simple mistakes like this should be easily avoidable. Personally, I can’t recall the last time I wrote an accidental assignment in this way. This seems like a lot of work to remember to do for something that rarely happens. This can also be caught with static analysers and linters. Automated testing should also catch things like this. It seems kind of “backwards” to take care of this in the code, especially this particular solution.

Yoda conditions create a lack of readability for not much return. In other words, the cons outweigh the pros in this case. Compilers in some languages produce warnings for accidental assignments in conditionals. Some languages even prohibit it (Swift, Python.)

When one gets into the === operator, it doesn’t help at all in that case. It seems that if one gets used to writing conditional statements like this, they end up writing out of habit.

if (true === $isSuspended) {
  // What am I doing here? Whyyyy?
}

Wanna check for null using PHP?

if (is_null($firstName)) { /* ... */ }

It’s a little disheartening to see that Symfony documentation and WordPress documentation both encourage it. Know better, they should. I'm not a superstar programmer like Fabien though, so I won’t pretend to know that I know more than him, but I would argue against suggesting Yoda in any code style guide.

See Also

• Why using Yoda conditions you should probably not be