The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,731 other followers

“Yoda Conditions” (from: stackoverflow – New programming jargon you coined?)

Posted by jpluimers on 2010/05/25

Having done quite a bit of C and C++ work in the past, I often still use “Yoda Conditions”, especially in environments where you have both = and == as an operator.
So, in a boolean expression, I often put the constant to test in front of the test.

I recently learned at stackoverflow that quite a few people call these “Yoda Conditions”:

“Yoda Conditions”— the act of using if(constant == variable) instead of if(variable == constant), like if(4 == foo). Because it’s like saying “if blue is the sky” or “if tall is the man”.

Thanks to dreamlax for helping me find that.

This is a problem in languages that have both the = and == operators, and the result of an assignment itself is also a value (i.e. allowing a = b = true).

In C# this still can go wrong with booleans.
Chuck Jazdzewski wrote a posting “zero the value is not” back in 2008, and Dan commented that C# still can fail with booleans.

For instance, in C#, consider this code:

bool a;
if (a = true) // Warning: "Assignment in conditional expression is always constant; did you mean to use == instead of = ?"
bool b;
if (a = b = true) // No Warning!

Both if statements will happily hop into the “then”, and write true to the console.
The first statement will get you a compiler warning, but the second won’t!

Code inspection, pair programming, turning on warnings, etc will help you prevent these problems.
But using Yoda Conditions will generate a compiler error in stead of a warning.

Looking at the comments on stackoverflow, lots of people seem to object to Yoda Conditions.
But there are other situations where the order of things is ‘constant value, expression to test’ too.

For instance:

  • Unit testing: for instance JUnit, NUnitDUnit and their father SUnit all have an Assert class that has assertEquals methods with parameters in the order “expected, actual”
  • When testing reference.Equals(constant) and the reference can be null, it is wiser to turn it into constant.Equals(rerference)

So are Yoda Conditions really thad bad?
I don’t think so. And reading the Yoda Conditions post by Clark Grub, he doesn’t either. He even adds a few more languages in his list (like JavaScript and Ruby).

What’s your take on this?


PS: Since I use many languages and environments (always pick the best tool for a job!), I tend to:

  • Use Yoda Conditions in other languages too
  • Always have parentheses around boolean expressions

The reason is that languages do differ in what they allow and require. Finding a common denominator that works in most languages saves a lot of energy.

via New programming jargon you coined? – Stack Overflow.

22 Responses to ““Yoda Conditions” (from: stackoverflow – New programming jargon you coined?)”

  1. […] Comments jpluimers on “Yoda Conditions” …auto Approve directo… on “Yoda Conditions” …Skydvrz on Crap: VersionInfo […]

  2. Have you ever thought about including a little bit more than just your articles?
    I mean, what you say is important and all. However think of if you added some great graphics or videos to give your
    posts more, “pop”! Your content is excellent but with images and video clips, this blog could definitely be one of the greatest
    in its niche. Awesome blog!

  3. Jon Jagger said

    Surely if you’re aware enough of the problem to reverse the operands you’re aware enough of the problem to check you’ve written == instead of =

    • jpluimers said

      The thing is: I’m not always aware of the exact writing of the operands. Which has to do with switching between many languages, and a mild form of dyslexia. So defensive programming helps.
      Of course YMMV (:

      Oh BTW: any new annotated C# reference in the pipeline? I absolutely loved the first edition ( and your hyperlinked C# 1.0 specs.

  4. […] Here's a nice overview with a few links to other articles… __________________ @AnthonySterling: A PHP […]

  5. Bob said

    In C and C++:

    NEVER EVER compare anything against “true” or “TRUE”. NEVER NEVER NEVER.

    Do NOT write

    if ( bValue == true )


    If you can’t code

    if ( bValue )


    then at least code

    if ( false != bValue )


    “false” and “FALSE” have a defined value, zero (0). “true” and “TRUE” are ANY OTHER VALUE.


    Please forgive the shouting. I’ve coded in C since 1978. It’s like a knife; people really should earn their totin’ chips before they are allowed to use it.

  6. […] malheureuse dans les conditions… ce que je ne savais pas c'est que cela avait un petit nom : Yoda Conditions […]

  7. […] this idiom deep into my brain: if (0 == someFunctionCall) { /* Apparently people call these “Yoda Conditions” */ […]

  8. Trillian said

    Please, I understand why you can feel the need to do this in C++, but don’t do this in C#. Using “== true” or “== false” is idiot anyways, so there’s really no problem here. The only edge case is when you do “if (a == b)” where a and b are booleans, but that alone doesn’t justify making all your conditionals mental speedbumps.

    • jpluimers said

      I used “true” and “false” for simplification: any boolean constant or other form of read-only boolean would do.
      My statement still holds: when regularly switching programming languages, it pays off having a defensive coding standard.

      If people are being bumped by this kind of comparison order, they will have immense trouble doing generics, yielding from iterators, lambda expressions, etc, won’t they?


      • Trillian said

        There’s a difference between having trouble understanding a concept and having a second of “huh?” every time you see an unintuitive construct like if (null == foo). I’m not alone in this situation, just see the comments on stackoverflow. I’m totally for defensive programming and I get your point, but C# and Java were designed so the probability of problematically interverting = and == operators is virtually inexistant, so I feel that using yoda conditions in those languages is being overcautious at the expense of readability.

        • jpluimers said

          I do understand, but C# did not eliminate the probability for boolean values.
          I have been bitten by this quite a few times already, so I have continued the yoda-style from other environments I have been active in, and I don’t have this “huh” any more.

          Of course this is a matter of style and taste, so please disagree :-)

  9. Guy Gordon said

    I use them in a single case: when a simple constant is being compared to the return value of a function. e.g.

    if (mrYes = MessageDlg(UserMsg.Message,mtConfirmation, [mbYes, mbNo], 0)) then begin…

    This improves readability over the standard, making it easier to see what condition will execute the ‘then block’, because the constant is not swimming out at the end of a long line.

    I also always put boolean expressions in parens.

  10. How about if you just used Equals(ArgA, ArgB) instead of the == operator? Then in languages that don’t support Equals you can write your own.

  11. Personally, I find Yoda Conditions ugly and difficult to read because they go against they way you think. They’re only used because the designers of the C language committed the massive wall-banger of formalizing in the language standard that anything can be a boolean, which is directly responsible for a great deal of syntactical ugliness and confusing-ness in C and the languages which descended from it.

    • jpluimers said

      Personally, you got the whole point about these things :-)

    • Warren said

      I would be in favor of removing the ability to use assignment in a boolean expression completely from the C language. Except, wait, you would then be unable to write
      a for loop. And there are lots of other cases where the sad little decisions they made, have doomed users of C to a lifetime of wrestling issues like this.


    • Dan Downs said

      But readability is what you just gained, it makes you not gloss over the common mistake and it includes intent. Doesn’t solve the “if Var1 = Var2” issue but its a step in the right direction.

      Reminds me of prefixing string vars with us/s/ds/js/etc… for unsafe/safe/DBsafe/JSONsafe whatever the intent is so when reading the code

      dsFirstName := usGetRequestField(‘FirstName’);

      looks wrong because a “us” string shouldn’t be assigned to a “ds” string.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: