Code Backwards, You Must: The Truth About Yoda Conditions
If you write java for a living, you spend more than an hour a day defending yourself against the billion dollar mistake: the NullPointerException.
You eventually have muscle-memory habits to shield your back. One of the most common is changing the order of equality checks so that the string literal is checked first, then the variable. I’ve been using this pattern for many years to avoid controller crashes in Spring Boot, but only now discovered that it is not just a Spring Boot pattern, that it is a naming and history of its own that is older than the Java itself.
This is known as Yoda Condition.
Syntax of a Jedi Master
Yoda condition is a programming style in which the constant, literal or expected value is on a left side of a comparison operator, while the variable is on the right.
You would write “If blue is the sky” rather than “If the sky is blue”.
In contemporary Java coding, that’s our go-to approach to avoiding null-pointers:
String userRole = null;
// The natural way: Throws NullPointerException
if (userRole.equals("ADMIN")) {
grantAccess();
}
// The Yoda way: Safely evaluates to false
if ("ADMIN".equals(userRole)) {
grantAccess();
}If userRole is null, the first approach will throw an exception because it is trying to call a method on a value that is null. The Yoda style uses .equals() on a sure string literal, returning the string literal’s value as a boolean smoothly with no exception.
History of Accidental Assignments
It’s tempting to think that this syntax was created just for the null safety of Java. It wasn’t. Yoda conditions first appeared in the C/C++ languages to address an entirely different and much more subtle problem: the “accidental assignment bug.
Get Debabrata Halder’s stories in your inbox
Join Medium for free to get updates from this writer.
In C, if statement evaluates numeric value. If the value is 0, then the result is false, otherwise it is true. This results in the notoriously hard bug to catch for a developer after missing a single key:
int retries = 0;
// Silent logic bug: assigns 5 to retries, evaluates as true
if (retries = 5) {
executeTask();
}By accidentally typing = instead of ==, the variable retries is reassigned to 5. 5 is “true” so the condition evaluates to true and the block is executed regardless of the value of the variable.
To avoid this, senior C developers began to reverse the process:
// Compile-time error: cannot assign a value to a literal
if (5 = retries) {
executeTask();
}The compiler is used as a safeguard by putting the constant on the left. The fact that a variable cannot be assigned to 5 makes it impossible to compile the program, which must be corrected by the developer.
The Modern Trade-off
In today’s world, conditions for integers and booleans have become pretty unpopular. An accidental assignment will be flagged as an error in modern IDEs, SonarQube, and linters. Not only that, but in a statically typed language such as Java, the if (retries = 5) statement won’t even compile because the if statement must be followed by a boolean expression.
In particular, primitive types have gained an anti-pattern that is writing if (5 == retries). It disturbs any flow of the mind in reading, forcing the reader to make a split second mind translation. Code is read much more than it is written and readability can almost always win.
However, for equality of objects, the pattern is still as important as ever. The next time you write “ADMIN”.equals(userRole), you’ll know you aren’t just writing defensive Java. You are propagating an age-old tradition of developers safely wrapping us in bubble wrap.
