Goodbye, Yoda conditions

Update: after additional internal discussions we’ve decided to reverse this decision. WooCommerce will continue to use Yoda conditions as outlined in the WordPress PHP coding standards to stay aligned with the wider WordPress ecosystem. We’re keeping the previous announcement for transparency.

Yoda conditions are a programming style in which the normal order of operands in comparisons are reversed. For example, if ( $foo == 34 ) would be written as if ( 34 == $foo ). The idea here is to avoid accidental assignments when a comparison is intended: while if ( $foo = 34 ) is syntactically correct PHP code and therefore will not throw an error, if ( 34 = $foo ) will throw an error and therefore keep a bug from being introduced.

Yoda conditions are part of the WordPress coding standards and since WooCommerce inherits these standards by default, this style of writing comparisons has been mandatory for any new WooCommerce code since the beginning.

Recently however, a proposal has been posted in the WordPress core forums to remove the requirement for Yoda conditions in the WordPress code. The reasons for this, as posted in the proposal itself and in the comments, are:

• Yoda conditions make the code harder to read. Code is written once and read many times, so read time convenience should be favored over write time convenience.
• The WordPress JavaScript code is already using regular conditions anyway.
• The problem they are trying to solve — avoiding accidentally writing an assignment instead of a comparison — is already handled by modern development tools (IDE warnings, linters and the like).
• Regular conditions seem to be the preferred choice for most developers. One analysis of the WordPress plugins directory is cited in the proposal, showing that only 18% of the conditions in all the scanned WordPress plugins are Yoda.

In light of this, and even though the original proposal for WordPress core has been rejected, the WooCommerce team has decided that Yoda conditions are no longer a requirement or are even forbidden — depending on the part of the code — for the WooCommerce codebase. We are aware that by doing this we are deviating from the WordPress conventions, but sometimes we need to implement changes like these to modernize the WooCommerce code.

(Other examples are the dependency injection container or adding new code as PSR-4-compliant classes.)

What does change?

The details are in the pull request that implements the change, but the summary is that starting with WooCommerce 6.9:

• Yoda conditions in the includes directory are discouraged, phpcs will emit a warning for these.
• Yoda conditions everywhere else (src, tests and templates directories) are forbidden. phpcs will emit an error for these, but phpcbf can be used to automatically fix these by converting them to regular conditions.

For reference, the specific warnings/errors that will be generated are:

• For code in includes: Usage of Yoda conditions is not allowed; switch the expression order (Generic.ControlStructures.DisallowYodaConditions.Found)
• For code elsewhere: Yoda comparisons are disallowed. (SlevomatCodingStandard.ControlStructures.DisallowYodaComparison.DisallowedYodaComparison)

No existing comparisons will be changed upfront.

It’s worth noting that the includes directory is considered legacy, thus no new code should be added there and existing code should get as little changes as possible. All new code should go into src.

However, includes is still where most of the WooCommerce code lives and what most of the community pull requests target, so we decided to take the “discourage” route instead of the “forbid” route here.

(We apply the “no new code in includes” rule strictly inside our team but not that much for community contributions, to keep things easy for everybody.)

How does this affect me?

If you have or plan to open pull requests targeting WooCommerce 6.9 or newer:

• For code that you add or modify inside includes you’ll see that when you run phpcs you’ll get warnings for Yoda conditions. We recommend to change them into regular conditions at least for code that you have introduced or modified, but it’s not mandatory.
• For code added or modified elsewhere (typically src) phpcs will throw errors for Yoda conditions, and this will cause the GitHub checks for the pull request to fail. These need to be changed into regular conditions, but this can be done automatically by running phpcbf.

This is a small step towards modernizing the WooCommerce codebase. Thanks for coming along with us on this journey. If you have any questions — please ask in the comments.