Computers have been my hobby since I was 12. Now I'm a freelance Java developer. Like many other developers I am working on various private projects. Some are open source components (Butterfly Components - DI container, web ui, persistence api, mock test api etc.). Some are the tutorials at Yet others are web projects. I hold a bachelor degree in computer science and a master degree in IT focused on P2P networks. Jakob has posted 35 posts at DZone. You can read more from them at their website. View Full User Profile

Are You a Yoda Programmer?

  • submit to reddit

When reading the code of my clients I often see many funny constructs. They are not wrong, just funny. Recently I spotted a new trend in some code I read. When I read it aloud to myself, it sounded like Yoda was speaking :-)

For instance

if(0 < myObject.theValue() ) {


When I try to understand foreign code, I usually kind of read it aloud to myself. Maybe not literally, but at least inside my head. Code like the above reads like

 "if 0 is smaller than or equal to the myObject.theValue(), then do XYX".

If you were to describe the business rule used inside this if-statement, you would probably have written it the other way around:

"If the myObject.theValue() is larger than 0, then do XYZ".

This way, the "myObject.theValue()"  is emphasized as the base of the rule, rather than the value 0, as is more the case in the first version.

The code version to make the code read more like version 2, would be

if(myObject.theValue() > 0) {


Or better yet, wrap the comparison inside a single-line method, explaining the business rule better:

if(hasValue(myObject)  { ... }


further explanation of business rule.

private boolean hasValue() {
return myObject.theValue() > 0;


Such single-line methods are inlined at runtime by the JVM anyways, so there is no performance overhead associated with it.

In my experience we read our code many, many more times than we write it. Thus, it makes sense in my opinion to invest a little energy in making it easy to read and understand.

Published at DZone with permission of its author, Jakob Jenkov.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Christopher Brown replied on Mon, 2010/12/06 - 3:30am

In Java, there's little advantage in expressing a comparison in "back to front" order.  However, in some scripting languages (which is probably where the programmer started), writing expressions in that way (using a literal value with an obvious type, here integer, for the first operand) forces (coerces) the second operand (if possible) to the type of the first, such as say forcing a string to an integer.


Joerg Viola replied on Mon, 2010/12/06 - 3:53am

There is one situation where I would write it that way:
if (0 <= a && a <= 5) {}

Nicolas Frankel replied on Mon, 2010/12/06 - 4:48am

That may be caused by the fact that in order to avoid NullPointerException, you write :

instead of

When a junior developer sees this for the first time, he usually questions it. When he gets the answer, there's a chance he will do it again everytime, even for no reason.

Philippe Lhoste replied on Mon, 2010/12/06 - 6:57am

Well, you introduced a bug in your refactoring...

But I appreciate the Yoda analogy! :-)

I believe this style of coding comes from C++, where operator overloading can introduce surprises in the second case, so they take the habit to put the constant part on the left (I don't recall the details, I fear).

You also find this inheritance when people declare arrays with String t[]; (which is accepted by Java, probably for legacy reasons, to avoid disturbing C coders).

Nils Kübler replied on Mon, 2011/02/14 - 5:05pm


Christian Schli... replied on Mon, 2010/12/06 - 8:03am

Thank you very much for coining this term - very funny! Being a Yoda Programmer, recognizing I do, your refactoring wrong is, little Padawan... :-)

Mladen Girazovski replied on Mon, 2010/12/06 - 11:48am

For example, if miss one "="-Sign, and write

if(a = 1) {}

the compiler will have nothing to compain about, but if you write

if(1 = a) {}

the code will not compile.

Appearantly you are not talking about Java, since in Java neither of your examples will compile.


Mark Haniford replied on Mon, 2010/12/06 - 12:17pm in response to: Joerg Viola

I like that.

Jakob Jenkov replied on Mon, 2010/12/06 - 1:16pm

Yearh, I put a bug in the refactorying... of course on purpose, to see if you caugh it!! :-D   ( :-( )

Nils Kübler replied on Mon, 2010/12/06 - 1:19pm in response to: Mladen Girazovski

Appearantly you are not talking about Java, since in Java neither of your examples will compile.

oops you are right :-)


Josh Marotti replied on Mon, 2010/12/06 - 3:53pm

Now may be a good time to interject that some developers still aren't familiar with apache commons jar.  Like common-lang's "StringUtils", "ArrayUtils", and "CollectionUtils" that have functions like "isEmpty()", "isBlank()".  These can make code a lot more readable (especially with static imports).

Zqudlyba Navis replied on Tue, 2010/12/07 - 2:30am

Disregarding the apache BooleanUtils, which would you prefer :

This ?

or this ?

Jose Fernandez replied on Wed, 2010/12/08 - 11:58am

Most of our code base is written in this style. I find it unintuitive and hard to read. @Nicolas: That's a very good rationale for putting the constant first, but it my years of programming, I have never had to do that. Likely it's because I null-check questionable objects before I use their methods. However in the case of Strings, I think your way is cleaner, so I'm going to switch. Thanks for the tip.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.