Yoda conditions

In programming jargon, Yoda conditions (also called Yoda notation) is a programming style where the two parts of an expression are reversed from the typical order in a conditional statement. A Yoda condition places the constant portion of the expression on the left side of the conditional statement.

Yoda conditions are part of the coding standards for Symfony and WordPress.

Origin

The name for this programming style is derived from the Star Wars character Yoda, who speaks English with a non-standard syntax (e.g., "When 900 years old you reach, look as good you will not."). Thomas M. Tuerke claims to have coined the term Yoda notation and first published it online in 2006. According to him, the term Yoda condition was later popularized by Félix Cloutier in 2010.

Example

Usually a conditional statement would be written as:

if ($value == 42) { /* ... */ }
// Reads like: "If the value equals 42..."

Yoda conditions describe the same expression, but reversed:

if (42 == $value) { /* ... */ }
// Reads like: "If 42 equals the value..."

Advantage

Readability of logically-chained comparisons

Some languages, such as Python, support "chained" comparison operators ("comparators") in their syntax. Thus, the following lines are logically equivalent:

# Using chained comparators:
if 3.14 < y <= 42: ...

# Logically equivalent to:
if (3.14 < y) and (y <= 42): ...

Notice that the second form naturally uses Yoda syntax in the left-hand comparison (3.14 < y). Consider the same line without Yoda syntax:

if (y > 3.14) and (y <= 42): ...

When handwriting math, many authors prefer the "chained" notation (example, example). When programming in a language that does not literally support the chained notation, the author may prefer the Yoda syntax, as it at least visually evokes the familiar chained notation.

Detecting programmer mistakes

For symmetric comparisons, such as equality, swapping the left and right operands does not change the behavior of the program. In programming languages that use a single equals sign (=) for assignment expressions, one might mistakenly write an assignment expression where an equality comparison was intended.

if (myNumber = 42) { /* ... */ }
// This assigns 42 to myNumber instead of evaluating the desired condition

Using Yoda conditions:

if (42 = myNumber) { /* ... */ }
// An error this is and compile it will not

Since literal expressions such as 42 are not assignable (they are not "lvalues"), assignment-equality confusion in Yoda conditions often manifests as a compile-time semantic error.

Boolean myBoolean = null;
if (myBoolean == true) { /* ... */ }
// This causes a NullPointerException in Java Runtime, but legal in compilation.
// This happens because Java will try to call myBoolean.booleanValue() on a null Object.

Changing the target of dynamic dispatch

In most object-oriented programming languages, the receiver of a method call is written to the left of the call's other arguments. At the same time, in non-Yoda comparisons, the variable that is the subject of comparison is written on the left-hand side. Comparison method calls are thus ordinarily dynamically dispatched on the object being compared, which is not always desirable.

String myString = null;
if (myString.equals("foobar")) { /* ... */ }
// This causes a NullPointerException in Java

With Yoda conditions, the call can be dispatched on a constant object instead.

String myString = null;
if ("foobar".equals(myString)) { /* ... */ }
// This resolves to false without throwing a NullPointerException

Criticism

Yoda conditions are criticized for compromising readability by increasing the cognitive load of reading the code.

Some programming languages (such as Swift, Kotlin and versions of Python below 3.8) do not allow variable assignments within conditionals—for example by requiring that assignments do not return a value, or by defining as part of their grammar the invariant that conditions cannot contain assignment statements—in which case this error is impossible to encounter (that is, it would be detected as a syntax error by the parser prior to a program ever being allowed to enter into runtime). Many compilers produce a warning for code such as if (myNumber = 42) (e.g., the GCC -Wall option warns suggest parentheses around assignment used as truth value), which alerts the programmer to the likely mistake. In dynamic languages like JavaScript, linters such as ESLint can warn on assignment inside a conditional. Python 3.8 introduced assignment expressions, but uses the walrus operator := instead of a regular equal sign (=) to avoid bugs which simply confuse == with =.

Another disadvantage appears in C++ when comparing non-basic types as the == is an operator and there may not be a suitable overloaded operator function defined. Example: a Microsoft's CComBSTR compare against a string literal, written as if (L"Hello" == cbstrMessage), does not map to an overload function.

External links

• What are Yoda Conditions? at the Wayback Machine (archived September 30, 2022)
• Yoda conditions very harmful seems to be Criticism of this technique, arguing that it can do more harm than good