Your father he is.

What do I mean by Yoda notation (also known as Yoda Conditions)? Let this simple graphic explain:

Yoda conditions (also called Yoda notation) is a programming style in an "if" statement where the two parts of the expression are reversed from the typical order. A yoda condition places the constant portion of the expression on the left side of the conditional statement. The name for this programming style is derived from the Star Wars character named Yoda, who spoke English with non-standard syntax. Instead of saying "if the count is five" he would say "if five the count is".

Origins

The convention originates from back in the C days, when one could assign a value to a variable within the if clause. For example, 

if (x = 0)
would actually assign the value zero to x. In those very early days of C (a long time ago, in a galaxy far far away), when one used to use the compiler just to compile and lint to check for various programmer errors, yoda conditions were actually useful. In those days the compiler would not warn you when you said "if (count = 5)" instead of "if (count == 5)". And no-one ever employed a compiler option to treat warnings as errors. No such compiler option existed. However, compilers have been warning about possible accidental assignment for decades now. There is no longer any need to use yoda conditions to guard against it. Furthermore, modern languages such as Java and C# do not allow variable assignment in an if clause. But people that still use the notation can't break the habit from all that time ago. The trouble is, such people write condition statements that force the reader to perform mental somersaults.

The fact is that for those languages where accidental assignment is still a possibility, the compilers have, for many years, warned about accidental assignment. The number of cases where they still fail to do this is incredibly small and tends for be or constructs that have obvious readability (and therefore maintainability) problems anyway, such as "if (a = b = true)". Just don't write code that is hard to read and maintain. It will be written just once but it will be read many, many times. Think of the readers.

It's all a matter of opinion, right?

Have you noticed how all smokers think that non-smokers exaggregate about the stink made by burning cigarettes? Smokers can't see why non-smokers get so riled up when there is hardly any smell at all as far as they are concerned. Non-smokers call the smokers behaviour and attitude anti-social but smokers think that the reaction of the non-smoker is extreme and most unreasonable. After all, it's all a matter of taste and opinion and it doesn't really matter, right? Well, I think that the reaction and behaviour of Yoda coders is similar. When you challenge them on the readability issue they claim that you are exaggerating and that it hardly makes any readability difference (smell, what smell?).

Emotions often run high when people talk about Yoda conditions. Just like they can do with smokers and non-smokers. Non-smokers call smokers anti-social and smokers call non-smokers reactionary millitants. This makes it quite difficult to debate the point. When pointing out the readability issues one often hears things like "but that's just your opinion, right?". The issue has thus become a bit like tabs versus spaces, vi versus emacs, the one true brace style, and so on. By claiming that the issue can be reduced to a matter of opinion then the discussion is essentially over. Which means that any coding guidelines will have to make a ruling on this point, the same as they will with tabs versus spaces and other style issues.

Closing thoughts

I have seen one argument that is the clincher, as far as I am concerned: "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 =". But doubtless the Yoda coder will have an answer for that. Probably something along the lines of "I automatically code this way so that I don't have to think about it".

There is an argument I hear from Java programmers who are Yoda coders. They say that 

if ("".equals(myString))
guards against myString being null. Presumably they would not say: 
if (myString != null && mystring.equals(""))
I think that if the coder really wants the code to handle a null string reference without throwing an NPE then the second form is much clearer. The first form just makes it look like the coder wanted to hide any bug that an NPE would reveal.

Some people say that Yoda notation should be used in the following situation: 

    In any language where assignment is = and equality is ==, and
    where assignment is legal in an expression, and
    where the compiler doesn't warn you of assignments used in expressions.
They say that this means C, C++ and Java. The fact is that all these languages no longer have this issue because the compilers all warn you about it. Plus, since we are all hopefully moving to the use of CI (Continuous Integration), we should have automated checks for this in the automated build. Personally, I would add something into the build checks to watch out for (and prohibit) Yoda notation.

For Java in particular, there is another blog article that speaks clearly on the subject.