Yoda conditions in Java .. a dangerous technique

A common practice I have seen is the placing a constant on the left hand side of an equality statement (usually called a Yoda Condition). Typically the constant is a string, and this constant is being compared to some other object, or method call on an object.

instead of on the right

I have seen it mentioned in many best practise documents, and seen it used by people such as Bruce Eckels.

The main reason to have the constant on the right hand side, the reasoning goes, is to avoid NullPointerExceptions, and also to avoid verbose code like this :

Why should this practise be avoided?

Consider this example :

In my EqualsTest class, I am crediting a customer in my creditCustomer() method. The conditional does a reverse equals check and throws an exception if the customer’s state equals “CLOSED”. Otherwise it procceeds to credit the customer.

Now say I, or someone else, creates a Customer but forgets to initialise the state (i know .. it probably should have been initialised in the constructor! But that is not the creditCustomer method’s problem.. It does not need to know the internals of the Customer object).

If the customer passes through the creditCustomer method, then it will credit the customer even though the customer’s state is null. Basically we have replaced the NullPointerException, or the system exception, with a business logic error which is harder to track. The business logic has been altered, and a user of the software is able to perform something illegal; that is crediting an uninitialised customer.

If we switched the equals around like this :

we would get a NullPointerException, and the end user would probably be rudely interrupted with an error message, however at least nothing illegal would have been performed.

Yoda conditions are also hard to read. They lacks flow. You have to read from right to left to make any sense of the statement (BLUE.equals(theSky)). It is not a natural way of reading.


Posted in Uncategorized | Tagged , , , , , | 2 Comments

2 Responses to Yoda conditions in Java .. a dangerous technique

  1. Rodrigo says:

    If customer == null || customer.getCustomerState() == null || customer.getCustomerState() != CLOSED, the RuntimeException is NOT thrown. So, I don’t understand your point about the customer passes through the creditCustomer method if I create a Customer but forget to initialise the state.

    • Christian Baune says:

      Take the time to read this sentence :
      “we would get a NullPointerException, and the end user would probably be rudely interrupted with an error message, however at least nothing illegal would have been performed.”

      NPE are not a bad thing and not catching the neither !

      Without using the Yoda condition, you have the benefit of NPE. Int that case, it is a synonym of “you didn’t gave me proper input”. It would pop very fast and one would handle that case properly. (Correcting on call site)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

THREE_COLUMN_PAGE