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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress.: 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 Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/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 JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. Coding Standards allow for closures to be used, we should be aiming to bring the PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 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 In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., 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 Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. 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