I had been using Yoda conditions for some time before I stumbled upon this now deleted Stack Overflow Question, later backed up in this blog post. I remember thinking "This could have saved me a lot of time!". Indeed, who can claim they have never written code like this:

<?php
if ($name = 'Luke Skywalker') {
   // this piece of code will always be executed
}

So how do Yoda conditions work? Well it is basically a knee-jerk reaction you have to develop: whenever you write a condition, put the operand that cannot be assigned on the left. This should give you an error message if you make an assignment when you actually meant to make a comparison.

In our case, this gives the following:

<?php
if ('Luke Skywalker' = $name) { // Parse error: syntax error, unexpected '='
}

and finally, if you go all in and use strict comparison, this:

<?php
if ('Luke Skywalker' === $name) {
}

In english, this translates to "If Luke Skywalker is the name", which should feel very familiar if you are from Dagobah or whichever planet Yoda actually came from, but is just cognitive load if you are used to english syntax, which you should if you are writing programs.

I believe it has to become a knee-jerk reaction because if it does not, there is no point to it: if you can think of using Yoda conditions, then for sure you can think of checking if you really mean to write an assignment here or not. You have to use them without thinking.

So let us say that you develop the knee-jerk reaction. You might end up with code like this:

<?php
if ('Luke Skywalker' === $this->getName()) {
}

Do you see the issue here? Neither operands can be assigned, so there is no benefit, but the downside is still there.

Soon enough, the disease spreads to inequalities, even in the documentation of my favorite framework, and you end up with needlessly convoluted code like this:

<?php
if (42 < $force) {
}

There are a few things to ponder before picking Yoda.

First, the only person who benefits from Yoda conditions, is you, the writer. It just makes life slightly harder for the people that read your code, which includes code reviewers, coworkers, or potential contributors.

Also, if you test every code path, you should be able to spot the problem before it reaches the next step of your development pipeline. Tests can help with that, especially if you write them before writing the actual code, in a healthy red-green-refactor cycle

Next, code review (including and especially self code-review) should catch the mistake if tests fail to do that.

And finally, if you are not feeling a strong need for assignments in conditions anyway, you may as well use a static analyzer to enforce a rule that forbids them. If you still would like to be able to use them you can also prevent Yoda conditions and only them.

So go ahead, get rid of Yoda conditions today, and death to the Jedi.