The WordPress Coding Standards: The Ternary Operator and Yoda Conditions

At this point in the series, we’ve covered a lot of ground. Up to now, we’ve discussed the following topics:

Naming Conventions and Function Arguments

The Use of Single Quotes and Double Quotes

Indentation, Space Usage, and Trailing Spaces

Brace Style, Regular Expressions, and PHP Tags

Lots of stuff, right?

In this particular article, I thought we’d take it a bit easier before jumping into the final topic. As such, we’re going to cover two really simple topics (that are often either ignored or overcomplicated).

Specifically, we’re going to talk about the ternary operator and we’re going to talk about Yoda conditions.

A Word About WordPress Conditionals

When it comes to writing WordPress-based code, the Coding Standards strictly say that we should aim for readability first. Straight from the Codex:

In general, readability is more important than cleverness or brevity.

But there is a bit of a nuance to this. Some developers consider the ternary operator to be a bit at odds with this particular principle specifically because it’s yet-another-way of writing an if/else statement, and if the developer isn’t familiar with writing or reading the ternary operator then it’s in violation of this principle.

We’ll take a look at this more in depth in a moment.

The Ternary Operator

First, for those who are not familiar, the ternary operator is a simplified way of writing an if/else conditional statement. It’s typically used only when the conditional is of the simplest form and only when there is a single if and a single else block.

For example, let’s say that we have a conditional like this:

1

2

3

4

5

6

7

8

9

$uses_gasoline=null;

if('hybrid'==$car_type){

$uses_gasoline=false;

}else{

$uses_gasoline=true;

}

echo$uses_gasoline;

Sure, this is a bit of a contrived example, but you get the point. After all, I’m simply trying to demonstrate how to convert a conditional like this into a form used by the ternary operator.

In keeping with the example above, you can do the following:

1

2

$uses_gasoline='hybrid'==$car_type?false:true;

echo$uses_gasoline;

Make sense? An important thing to notice: the ternary operator is testing for true (rather than false, obviously).

For what it’s worth, I find this to be a lot like reading a sentence. The first clause is asking a question (obviously punctuated by a question mark), with the two possible answers returned based on the evaluation of the conditional.

There is one caveat for checking for true all of which is documented in the Codex:

An exception would be using ! empty(), as testing for false here is generally more intuitive.

In my experience, that’s been the only time to use a negative evaluation in the conditional. All of the times that I’ve spent working with the ternary operator, I’ve found that testing for false often makes the ternary evaluation more difficult to decipher.

Additionally, I’ve found that it’s best to provide a single evaluation and maybe two evaluations under very simple, clear circumstances.

Other than that, that’s how you can use the ternary operator in your day-to-day WordPress work

Yoda Conditions

If you were following along closely, you’ll notice that I did something that most programming languages (or even PHP-based platforms outside of WordPress) don’t regularly do:

The conditional’s comparison was done by comparing the value to the variable; not the other way around.

Traditionally, we’d see something like this:

1

2

3

4

5

6

7

8

9

$uses_gasoline=null;

if($car_type=='hybrid'){

$uses_gasoline=false;

}else{

$uses_gasoline=true;

}

echo$uses_gasoline;

And the corresponding ternary operator would look something like this:

1

2

$uses_gasoline=$car_type=='hybrid'?false:true;

echo$uses_gasoline;

So if the majority of programming languages and platforms don’t use Yoda conditions, then why does WordPress?

According to the Codex:

In the above example, if you omit an equals sign (admit it, it happens even to the most seasoned of us), you’ll get a parse error, because you can’t assign to a constant like true. If the statement were the other way around ( $the_force = true ), the assignment would be perfectly valid, returning 1, causing the if statement to evaluate to true, and you could be chasing that bug for a while.

In my opinion, this is a really, really good explanation for performing comparisons like this especially within dynamically typed languages such as PHP and JavaScript.

Regardless of if you agree with this approach or not, it is part of the standard and you are going to see this used through WordPress core, themes, plugins, articles, and more.

To that end, I highly recommend beginning to implement in your own work.

Conclusion

As I mentioned at the beginning, this particular post was going to be much simpler and straightforward than some of the other material that we’ve covered in the series thus far.

At this point, we only have one more major topic to cover: Database Queries.

After that, we’ll be doing a review of all of the topics that we’ve outlined throughout this series in order to summarize the principles we’ve detailed from the Coding Standards.