Why using Yoda conditions you should probably not be

Grégoire Paris on August 02, 2017

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. ... [Read Full]
markdown guide

In some languages (like java) yoda-conditions also give you null handling:

if (variable.equals("value")) ...

throws an exception if variable is null

if ("value".equals(variable)) ...

will work correctly

if ((variable != null) && variable.equals("value")) ...

is more work and potentially error-prone.


Can you really call it a "Yoda condition"?

Yoda conditions have been born to avoid hard-to-catch mistakes, like an assignment in a condition statement. If variable is null in your first example you catch it immediately, because it throws a NullPointerException as you mentioned.

So it doesn't save you from a mistake; it saves you from checking if the value is null or not. And honestly I'm not sure it's what I'd want: if I expect a string there, why am I dealing with null?


Now there's Objects.equals(variable, "value") as well... although it looks sloppy at first it's very useful for lambdas


TIL. That's a good usage of Yoda conditions.



That's all we need. Linters can easily catch problems like this one. And many others, of course.

So let's forget about Yoda conditions, like we forgot about the Hungarian notation and other hard-to-read conventions.


Or languages designed with code safety in mind, which prohibit these kinds of expressions.

For example in Swift (and other type safe programming languages), the following expression results in a compile time error:

if name = "Luke Skywalker" { // error: use of '=' in a boolean context, did you mean '=='?
    // ...

Yoda conditions are a lot like the Hungarian notation: it's a "clever" trick that help you catch mistakes for every gazillion time you use it. Just not worth it.


I see your point and I agree to some extent. But the main reason you apply Yoda conditions is to fail first.

Basically it's the same reason why you have declare(strict_types=1); on the first line of your code.

Yes, readability is somewhat shattered but you gain better control over your code flow. Especially when you're developing for resilience. In huge codebases normal condition statements are overlooked and tests don't cover these conditions. Especially when dealing with legacy code.


You can still use code review and linters with legacy code though. And unit tests, if you can decouple new code you introduce from the legacy code.

but you gain better control over your code flow.

What do you mean by that exactly?


I think this is a lot like the story where a daughter asks her mom why she cuts the ends off the roast before she cooks it. Her mom says that grandma used to do it that way, so she did as well. When grandma is asked by the daughter, she says that she did it because the roast was too big for her small pan...

Honestly, this style of programming came out of necessity. We used it back in the old C/C++ days because the tooling and testing support just wasn't mature compared to today. I remember the first time we upgraded the compiler to a version that would detect this condition. We had all sorts of hidden bugs instantly visible.

I think the reason this style has persisted so long, is that older developers have passed it down due to the development scars we carry from years ago. I do find myself writing this type of code, for the very reason that it's just the way I have always done it. It is good to see these beliefs being questioned, and it will probably change the way I code from here on, just due to it being pointed out. It you have the tooling and testing support, there is just no valid reason to drop in a Yoda condition anymore.


Nice story, didn't know that one, but it's definitely similar!


'Luke Skywalker' === $this->getName() is not relevant, indeed. This why you should not use it for this and only for this.

AFAIK, Symfony rules require yoda condition only if useful.

P.S.: I'm already far far away ! <3


Agree do I. Yoda conditions I used as well. Better tools we now have, catch errors they will. Useful some cases remain, as comments say, but needed simple cases no longer are. Writing like Yoda difficult is, and reading like Yoda hard is too.


Rewrite the whole post in Yoda I definitely should. On the head, the nail would be hit.


Sounds like something a sith would say 🤔.

All jokes aside great article, I don’t program much in PHP anymore but when I did “Yoda Statements” on occasion a yoga statement would pop up in my code, and it frustrated my co workers and anyone reviewing my code; You don’t see anyone addressing them often, I’m glad you wrote this article.


Thanks a lot! It has been bothering me for a while, and I needed a reference to avoid repeating myself :)

What's wrong with the Sith anyway? reddit.com/r/EmpireDidNothingWrong/


I'm so glad you wrote about this! Writing Yoda if-statements just to avoid potential typos just seems backwards, your automated test suite should catch them issues!


And I'm glad to see I'm not alone! Thanks!


I also have a personal beneficial side effect to Yoda:

if (1 == function(so many parameters)) {

seems so much easier to read than

if (function(so many parameters) == 1) {

because I immediately have the constant and the function name(and the return values of that function to an extent if code is documented and IDE actually does it's job).

I find it easier than scrolling through the whole list of parameters just to find out what I'm comparing to.


If the parameter list is so long that you need to scroll, you need to use some linebreaks. See my other post, dev.to/greg0ire/why-i-keep-pesteri...


Could the entire situation be avoided by using an editor linting plugin to detect assignment within conditions?


It very much could, this is a great idea if you don't need assignments within conditions.

code of conduct - report abuse