Do people struggle with Yoda conditions for real?

I’ve been using, and advocating for others to use, Yoda conditions for a long time. Sometimes, I read or hear about someone who doesn’t like them, without actually describing why. From time to time I read a blog post that advocates against it: And it’s always the same reason.

One of the better blog posts advocating against it is this one: “Why using Yoda conditions you should probably not be” by Grégoire Paris. If you don’t know what Yoda conditions are, you should absolutely read it before continuing.

The problem seems to always be: “It is hard to read!”
My reaction is always: “Really? No, it’s not.”

When you see code like this:

if ( 'foo' === $bar ) { }

Do you really read it out, slowly, word by word like a child, in plain English?
“If … the string … containing ‘foo’ … is exactly equal to … the variable named ‘bar’ … then”

Or do you see a conditional structure with a comparison between two objects that must be exactly equal?

Children who are learning to read, must practice to see words as a whole instead of reading them out syllable by syllable. Until they do that, we say that they are learning to read. Once they do that, we say that they know how to read.

There are some variations of this text online. It is all messed up, but you can still read it, right?

The phaonmneal pweor of the hmuan mnid, aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it dseno’t mtaetr in waht oerdr the ltteres in a wrod are, the olny iproamtnt tihng is taht the frsit and lsat ltteer be in the rghi t pclae. The rset can be a taotl mses and you can sitll raed it whotuit a pboerlm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe. Azanmig huh?

I agree, that it would be easier to read this text if the spelling wasn’t messed up, but you can still read *that*. Now you’re telling me you’re supposed to be a professional coder, but are having trouble with reading “something here should be exactly equal to something there”?

I think you don’t like Yoda conditions because you’re used to writing code in a different way, and you don’t like being corrected. At least not over something that’s not a big deal (Yoda conditions are not a big deal, it’s just a helpful habit to avoid errors).

11 Comments

  1. I agree that it’s not a big deal, but I disagree with most of the rest. I don’t like Yoda conditions. I think it makes the code slightly harder to read and reason about without giving any big benefits. You must be really sloppy if you regularly put a single = in your if statements by mistake and it’s very easy to spot. I can’t recall the last time I made that error and I don’t think I’ve ever encountered a bug caused by this that was not very easily fixed(almost as easy as a syntax error). Most good editors or linters will even show you a warning/notice when you do assignments inside an if-statement.

    After all, the code is only written once, but will probably be read a lot of times, so you should probably optimize your code for readability.

    1. I highly agree on the point of optimizing code for readability. “Clever” code should be avoided. However, I like Yoda conditions and I don’t find them harder to read at all. Maybe something in my brain is wired backwards.

      Well, perhaps I might be sloppy, since I’ve done the mistake of using a single = several times. It is, however, a long time ago now, and I’m not sure if that should be contributed to using Yoda conditions or strict comparisons with ===. But when that mistake happens, it is frustrating to debug since your code is syntactically valid and the human brain is a cognitive mess wired to see what it believes is there.

      When this happens, I agree that one has clearly not been using a proper toolset for coding. I cowboy code all the time to do quick tests of things that must be done on a live (not prod) server. Maybe it’s time for me to install a linter in Vim, but with the habit of using Yoda conditions (and strict comparisons) I don’t require anything extra at all.

      To end the debate, maybe we can adopt the Perl “motto”:

      If it was hard to write,
      it should be hard to read!

  2. I was probably a bit too harsh when I called other developers sloppy. If you, like you said, make a habit of thinking about whether you should use strict comparison or normal comparison every time you write an if-statement I think there will be very few cases where you will leave your if-statement with an assignment by mistake. So thinking about that is probably an easy way to minimize this mistake.

    1. I guess I set the bar for harshness quite high in the post, so I think you’re well within acceptable limits here ;-)

      I still like Yoda conditions, and they’re not hard to read!

  3. I can, of course, read Yoda conditions without any problems, it’s just that I think the flow is a bit weird. For more complex if-statements it might take me a few seconds more to figure it out, but that is probably more because I’m not so used to it.

  4. Hi! Nice blog post!

    > Do you really read it out, slowly, word by word like a child, in plain English?

    No I don’t. In my head like an adult I read them, and some sense it still makes. Struggling I can’t say I am. But an unneeded distraction it becomes, when on the meaning of the sentence I would like to focus instead.

    > I think you don’t like Yoda conditions because you’re used to writing code in a different way, and you don’t like being corrected

    I actually have been using Yoda conditions for a short time, and finally decided to revert back to how I was doing before, because of the very little return on investment.

    > Children who are learning to read, must practice to see words as a whole instead of reading them out syllable by syllable. Until they do that, we say that they are learning to read. Once they do that, we say that they know how to read.

    Yes, but to ease the understanding one has of your programs, you should try to make your code as close as possible as what you would say to describe the algorithm in pseudo-code: “If the name is Bjørn”, and not “If Bjørn is the name”

    > When this happens, I agree that one has clearly not been using a proper toolset for coding. I cowboy code all the time to do quick tests of things that must be done on a live (not prod) server. Maybe it’s time for me to install a linter in Vim, but with the habit of using Yoda conditions (and strict comparisons) I don’t require anything extra at all.

    I’m a fellow vim user, and have not setup any rules to prevent that kind of mistake. I remember doing it some years ago, but it has been a really long time. Maybe I have learnt to pay attention during the short period of time I used Yoda?

    1. Thank you for sharing your thoughts and experiences, and for a great comment!

  5. “I think you don’t like Yoda conditions because… you don’t like being corrected.”

    This is my biggest problem with yoda conditions. I don’t find them harder to read (at most I find them maybe unnecessarily different), but every programmer I’ve personally encountered who prefers yoda conditions has had an air of superiority and a “you’re the one doing it wrong” attitude, when to me it really just boils down to personal preference that should probably be overruled by codestyle agreement within a given team.

    It sometimes feels like a tabs-vs-spaces argument where the spacers are berating the tabbers. Kinda like that, but on a mix of really strong steroids.

    1. Thank you for your comment!

      I have a strong opinion on tabs vs. spaces too, but I know that is actually just personal preference. Whereas yoda conditions actually helps you write better code.

      I know I wrote this post in a provocative style. Maybe that was wrong. IDK. But I wanted to tackle the *only* argument against yoda conditions I’ve ever seen: That it is hard to read. Maybe it is hard to read for some (or many, or most), but I don’t want people to use that argument without first doing a reality check.

  6. Space vs tab, better spaces as constant size.
    Yoda or not. Depends on the check. In boolean(true, false) and null as a inherited from C would be better also for reading, all other examples are misunderstanding of yoda notations in C based syntax without strict type boolean expression checking.
    So php is like C different from 0 is basically true. There is a type inference as well in play. There is nothing wrong 1 way or another. Specific case might be biased.

  7. Great post and interesting comments!

    I support yoda conditions not because I hold an opinion based on someone else’s opinion handed down to me from the programming elders, instead, it’s because I see value in getting more out of everything and anything where possible. Yoda conditions give you something for free without any extra effort, the logical validation of your code working and not quietly evaluating incorrectly and leaving you with that debugging nightmare mentioned previously.

    Sure IDE’s and linters will quickly identify the issue but you’re now relying on external indicators not to mention your ability or lets also say observation to acknowledge the indicators and correct the mistake… if you’re human enough to make the mistake then you’re also human enough to miss the warnings ( unless you have a fortnox CI pipeline pulling up every linter mistake… a topic for another day I am sure… )

    I think most people seem to suggest that as programmers we all can read code because we don’t read code like you would read a book, instead, we read code as we see it logically executed ( if this is not how you read code then perhaps you should be writing and reading books instead ) when you’re comparing something on the left with something on the right ( or something on the right with something on the left ) it really doesn’t matter what they are… be they a variable or a defined string in the comparison, instead, you consider if they conditionally resolve to the operator between them… in this case the operator is equals.

    Lastly, I do actually assign values to variables inside my condition blocks of which I am sure some people will cringe, however, its great for defining and assigning to a variable for usage inside the resolved condition block. This means that once I am inside the conditional block of logic, I don’t need to define and assign the value to a variable, instead, I can immediately start referring to the variable.

    for example:
    if (null !== ($string = array_get($array, ‘key.subkey’, null))) {
    echo $string;
    }

    Its possible a linter will hate the above but its valid and yoda protected as I am using yoda to condition but non-yoda to assign values to variables.

    I really hope the above helps shed some light on why yoda is free of charge validation and that hopefully people will consider the benefits of yoda over the difference of opinions.

Comments are closed.