Home > Programming > Yoda conditions

Yoda conditions

October 20th, 2010 Leave a comment Go to comments

I never liked, agreed with or used these much until I found them as a rule in a “coding practices” document lately, document that I’m supposed to be following. Luckily, it’s just an optional rule…
So what is a Yoda condition? It’s a practice of reversing the normal order of the operands in an equality condition and placing the constant (or, more generally, something that is not an LHS expression) on the left of the operator; instead of writing for example

if (variable == 0)
{
...
}

you would say

if (0 == variable)
{
...
}

The reason some people practice and support this is that it guards against the “common” mistake of using ‘=’ instead of ‘==’ to test for equality.
Why I personally don’t like it:

1. I don’t like things that start from the premise that I’m an idiot.
People say this is a common mistake, generated by the fact that people are used to using ‘=’ and not ‘==’, because in all the arithmetic and mathematics studied in school they only used ‘=’. True, and what did they use it for? Testing for equality? I don’t think in mathematics there is the need to have an operator for “testing for equality”, so I don’t see why this would be the problem.
True, until you start programming in one of the languages in which ‘==’ is used for equality testing and ‘=’ for value setting, you are only accustomed to using a single equal sign. But as a C/C++ coder this changes and you must get used to using the language properly.

2. It makes the code look weird and hard to follow for someone who is not accustomed to it; readability should be a critical concern when writing code.

3. It’s easily and very often abused.
It’s intended purpose is related only to equality, but once they start using it people usually get carried away and always do it. For example, if you want to test if a variable is inside an interval, you see something like this:

if (RANGE_START < variable && RANGE_END > variable)
{
...
}

Here the first inversion is natural but why the second? What’s the risk? That some idiot might write ‘=’ instead of ‘<’?

A slightly more subtle method of abuse is that it eventually leads to code like this:

if (false == variable)
{
...
}

or even worse

if (true == variable)
{
...
}

There are situations when doing it Yoda style is acceptable and these are when it feels natural or when it actually helps readability instead of hurting it. We’ve already seen one such situation: testing if a variable is inside a range. In mathematics we would write this as:
RANGE_START < variable < RANGE_END

so in code we might write:

if (RANGE_START < variable && variable < RANGE_END)
{
...
}

Another situation is when the value to be tested is the result of a method call or a complicated expression. In these cases it might be easier to read the whole expression if it’s written as:

if (false == SomeMethodCall(arg1, arg2, arg3))
{
...
}

instead of the other way around. But this depends on the actual situation and the person writing (or reading) the code and it’s purpose is only to improve readability.

For protecting against stupid mistakes lets use the compiler. Probably all modern compilers can be made to generate an warning for this kind of thing. And of course we all build with “treat warnings as errors” set to on, right?
For example, gcc says something like this when compiling with -Wall:

warning: suggest parentheses around assignment used as truth value

Visual Studio 2008 generates the following warning (if proper settings are activated):

warning C6282: Incorrect operator: assignment of constant in Boolean context. Consider using '==' instead
  1. May 4th, 2011 at 14:54 | #1

    I feel so much happier now I understand all this. Tnahks!

  2. July 24th, 2012 at 18:28 | #2

    A Yoda condition, it is. Get used to it, you will.

  1. No trackbacks yet.