Naming Conventions: What’s the Big Deal?

Most people with a passing knowledge of computer science understand the need for something like “a = 1” – but they might be super-confused by “1 = a”!

Are computers confused, too? Not necessarily – but the issue of syntax is a big one for determining how programmers work together. Will this kind of syntax dyslexia sink the ship?

One of the big questions about how to format code has to do with “Yoda conditions” (named for the “Star Wars” character known for his unusual English syntax), a kind of flip-flopping of a variable and an assignment, as shown above. The standard, again, is to say that a variable “a” equals some number, not to start with the number and assign the variable that value. (To learn about the history of programming, check out Computer Programming: From Machine Language to Artificial Intelligence.)

Do or Do Not?

Programmers agree that Yoda conditions can be confusing to readers, but their attitudes differ slightly on whether this technique should ever be used.

Tonya at WP Developers Club takes on this issue with a detailed and visual article – “To Yoda or Not to Yoda?” in which she suggests that there can be legitimate times to turn these code statements around.

Tonya points out that using Yoda conditions can help prevent unwitting value assignments caused by a typographical error. If the parameter uses a single equal sign (=) instead of a double equal sign (==), the computer will assign a variable the value, rather than check to see if it is equal to that value. Putting the value first can help catch this error. Tonya also talks about some best practices and myths around this kind of syntax, such as the idea that Yoda conditions can cause a computer to run faster.

“Yoda conditions is one programming style to deal with one specific problem,” Tonya writes. “It does not profess to solve other problems. When properly applied, it can minimize the effects of typos for assignment when you meant to compare. Practitioners know its trade-off is readability.”

Unusual, It Is

In a blog post on Pushing Inertia, another programmer named Dan talks about the double-take that programmers do when they notice this unusual condition, in his particular example, in an “if” statement:

“It was already rather challenging to trace through the logic, and seeing this notation sprinkled throughout the code just added more mental complexity.”

Dan goes on to talk about how programming logic should follow some of the language conventions we use in English and other world languages, to make things easier on second-party readers. He talks about the old days of C and other languages, and how modern languages have written the Yoda conditions out of the playbook. (To learn more about programming conventions, see An Intro to Logic Trees and Structured Programming.)

Dan also suggests that using a final keyword in Java can make things clearer.

“I would say that in well-written code, about 85% of variables can be marked as final, preventing any possibility of reassignment. Note that I’ve stated above that ‘final’ makes the memory reference immutable. This means that you can still have a variable of type Map or Set and freely modify its contents, but you cannot assign a new map or set to the variable. The only variables that I don’t mark final are iterators, such as a counter in a loop and possibly a return value… in summary, usage of the final keyword will prevent a lot of accidental code problems and eliminates any possible need for Yoda notations. It also has the nice effect of forcing code into small, logical, methods that are easy to unit test and easy to understand.”

StackExchange, a major forum for pro discussions, is staying out of the fray. Site moderators responded to a question about Yoda conditions with this statement:

“As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion.”

Zeel Jadia is Senior Vice President of Engineering at Events.com. “I find naming conventions to be very useful, to help with readability and consistency,” Jadia said in response to a question on enforcing code standards.

“This helps different developers on the same team feel more at-home in different areas of an application and makes them that much more productive. The key thing is it has to be initiated from day one and enforced by internal standards and reviews…as far as Yoda conditions go, I’m torn: Compilers and some languages can protect us already against the things that Yoda conditions try to overcome. But on the other hand I love Star Wars and Yoda was an awesome Jedi.”

Enforced, Standards Must Be

To Jadia’s point, there are a lot of situations where coders don’t have a choice – those standards have already been enforced for them. Whether or not you have the ability to decide to “do Yoda conditions” or not depends on the context of your programming project. For example, take a look at this “guide” from WordPress on PHP that exemplifies the type of standards that companies are either suggesting, or enforcing, depending on their outlook. The WP guide contains all sorts of thou-shalts and thou-shalt-nots on everything from naming conventions to space usage. Here’s what it has to say about Yoda conditions:

“When doing logical comparisons, always put the variable on the right side, constants or literals on the left…(otherwise)…if you omit an equals sign… you could be chasing that bug for a while. A little bizarre, it is, to read. Get used to it, you will.”

However, this command does not extend to other code scenarios:

“This applies to ==, !=, ===, and !==. Yoda conditions for <, >, <= or >= are significantly more difficult to read and are best avoided.”

There you have it.

This is one of those thorny questions that teams can talk about in-house when they have their weekly meetings. However, it’s helpful to know why this kind of thing is done, what the overall consensus is, and what stricter or looser code conventions can deliver.