Yoda conditions

Short description: Computer programming style

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

Error detections

Placing the constant value in the expression does not change the behavior of the program (unless the values evaluate to false—see below). In programming languages that use a single equals sign (=) for assignment expressions and not for comparison, a possible mistake is to assign a value unintentionally instead of writing a conditional statement.

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

Using Yoda conditions:

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

Since 42 is a constant and cannot be changed, this error will be caught by the compiler.

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.

Avoiding some types of unsafe null behavior

Yoda conditions help with unsafe behavior in some situations.

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

With Yoda conditions:

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 =.

The advantage of avoiding null behavior can also be considered a disadvantage, as null pointer errors can be hidden and only appear much later in the program.

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

• united-coders.com: What are Yoda Conditions? Examples in Java
• Yoda conditions very harmful seems to be Criticism of this technique, arguing that it can do more harm than good