This is a follow-up to several changes proposed a few months ago.
While reading these changes, it’s important to keep in mind that they only apply to WordPress Core: you can (and should) choose practices that best suits your development style for your own plugins and themes. The coding standards are intentionally opinionated, and will always lean towards readability and accessibility over being able to use every possible language feature.
Closures (Anonymous Functions)
There was quite a lot of discussion around this proposal, particularly with regards to allowing closures as hook callbacks. Thank you everyone for your input, and for keeping disagreements respectful. 🙂
We do need a decision, however, and there were several key points that led to this:
- It’s currently difficult to remove closures as hook callbacks. #46635 has several interesting proposals to address this in an entirely backward compatible manner.
- While WordPress Core should strive to allow any callback to be unhooked, plugins have no such restriction.
- The WordPress JavaScript Coding Standards allow for closures to be used, we should be aiming to bring the PHP standards in line with that.
- The broader PHP world has embraced closures for many years, and have found ways to use them responsibly. We shouldn’t ignore PHP usage outside of WordPress.
With these points in mind, a conservative, but practical step is to allow closures as function callbacks, but not as hook callbacks in Core. Ultimately, we should be able to allow any sort of complex callback to be attached to hooks, but the Core APIs aren’t quite ready for it yet.
Coding Standards Change
Where appropriate, closures may be used as an alternative to creating new functions to pass as callbacks.
Closures must not be passed as filter or action callbacks, as they cannot be removed by remove_action() / remove_filter() (see #46635 for a proposal to address this).
Short Array Syntax
A little less controversial, but still with varying opinions, was the proposal to require short array syntax ( [ 1, 2, 3 ] ) instead of long array syntax ( array( 1, 2, 3 ) ) for declaring arrays.
While I’m personally partial to short array syntax, there were two particularly convincing arguments for using long array syntax:
- It’s easier to distinguish from other forms of braces, particularly for those with vision difficulties.
- It’s much more descriptive for beginners.
So, this change to the coding standards is the opposite of what was originally proposed, but is ultimately the more inclusive option.
Coding Standards Change
Arrays must be declared using long array syntax in WordPress Core.
Short Ternary Operator
The original proposal was to allow the short ternary operator, but this change reverses that. There’s a good argument that it looks too much like the null coalesce operator, especially as they perform different functions.
Take the following example from Core:
$height = isset( $data['height'] ) ? $data['height'] : 0;
It’s not possible to reduce this line with the short ternary operator, but it can be trivially reduced with the null coalesce operator:
$height = $data['height'] ?? 0;
The vast majority of other ternary operators in Core (which don’t have an isset() test) look something like this:
$class = $thumb ? ' class="has-media-icon"' : '';
This also can’t be reduced using the short ternary operator.
As the null coalesce operator is a useful addition (which we’ll be able to use once the minimum PHP version bumps to 7+), whereas the short ternary operator can only be used in a handful of cases in Core, it’s better to avoid the potential confusion, and not use the short ternary operator.
Coding Standards Change
The short ternary operator must not be used.
Assignments Within Conditionals
Particularly when there are multiple conditions, it can be quite difficult to spot assignments occurring in a conditional. This arguably falls under the Clever Code guidelines, but hasn’t been formalised.
I got a little ahead of myself with this one, and have already removed all assignments in conditionals from Core. Adding this change to the standard formalises the practice.
Coding Standards Change
Assignments within conditionals must not be used.
#php, #wpcs
