The PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher files in WordPress core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. become cleaner and easier to read with every release, thanks in part to our standards for PHP code style. Our 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/., on the other hand, hasn’t gotten nearly enough love. This post is intended to open up the recent discussion around JavaScript style to the greater community so we can make up for lost time.
Don’t we already have a style guide for JavaScript?
Back in March, @tommcfarlin added a set of coding standards for JavaScript to the developer handbook. These WordPress JS coding standards are a great work-in-progress, but weren’t fully comprehensive (leading to some comment threads clarifying various areas). More importantly, without any clear implementation plan the style guide failed to gain traction.
At WordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Boston’s core contributor day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. I revisited this style guide with @mattwiebe and Corey Frang (@gnarf37). It is important to identify *and implement* conventions for JS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. style ASAP because syntax issues in the JS within WordPress may hide latent bugs, and inconsistent code discourages contribution. Focusing on implementation lead us to look for an existing, proven JS style guide with a .jshintrc
file (a set of configuration options for the JSHint code quality tool) which we could adopt largely as-is: Getting JSHint in place lets us see the biggest issues in our JS, so we can begin tackling them incrementally (perhaps in the same manner as the inline docs effort).
After looking at Idiomatic.js and several other widely-adopted JS style guides, we feel the jQuery Foundation’s jQuery Core JavaScript Style Guide guide is the closest match for what we need in WordPress.
Adopting the jQuery Core JavaScript Style Guide
jQuery’s guide shared WordPress core’s love of white space—the same “when in doubt, space it out” mantra from the existing JS style page. Moreover, jQuery’s code conventions have been referenced in trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets as an example of how we should be writing our code. Adopting their guide wholesale capitalizes on our stylistic similarities, and will let us adopt their .jshintrc
and any future code quality tools they write with minimal changes.
Adopting this guide means making two primary changes to the way that we have been writing JS:
-
Strict Equality
We need to move to using ===
instead of ==
. We’ve been getting away with using the double-equals in WordPress, but enforcing triple-equals (“threequals”) will avoid the unpredictability of type coercion. To quote the aforementioned Idiomatic.js, *evaluate for the most accurate result*. It is not intuitive that "10" == 10
will be true
despite the string/number type difference, and unintuitive code should be avoided.
-
Consistent curly braces
Every widespread JS style guide prefers enclosing single-line statements in curly braces, and we should too. If you always use brackets, adding other statements to a block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. later is trivial; if they are not present, adding new statements can lead to bugs. We don’t require braces for single-line conditionals in our PHP standards, but it is noted that having them “allows for fewer line edits for debugging or additional functionality later.” They also make the presence of blocks more obvious, particularly when the “single-line” statement is a complex jQuery operation.
Consider:
// Two lines, one statement
if ( someString === 'desired value' )
$( '.class-name' ).show().value( someString + '!' )
.on( 'click', doSomething );
// Only three characters more, easier to "eyeball," and easier to add
// additional statements to the conditional block later on
if ( someString === 'desired value' ) {
$( '.class-name' ).show().value( someString + '!' )
.on( 'click', doSomething );
}
We believe making these big changes and the other smaller consistencies found in the jQuery style guide, will improve the reliability of our JavaScript and should be integrated across the JS files in WordPress.
Exceptions
There are two specific areas where we plan to *deviate* from the jQuery Core Style Guide to maintain readability & consistency with existing styles:
- We will use Single Quotes for strings
jQuery’s guide specifies double quotes for string declaration. The existing WordPress JS uses single quotes, and we prefer to keep this as-is: JS strings in WordPress will continue to use single quotes.
- Iterator variables declaration
jQuery specifies that iterators should be initialized when the variable is declared, at the top of the function; this is done as a minified file size optimization, but is extremely unintuitive for inexperienced JS devs. To quote Aaron Jorbin, who raised this issue, “I would rather optimize for developer happiness.” Example below.
// Confusing
var i = 0;
// A bunch of lines of other code
for ( ; i < 100; i++ ) {
// Expressions -- but how many? Where did `i` get declared, again!?
}
// Preferred / More readable
var i;
for ( i = 0; i < 100; i++ ) {
// Expressions
}
Next Steps
@nacin has landed an adaption of jQuery’s .jshintrc file in Core, and once we’ve gotten some comments with feedback to this post I will update the Handbook’s JS standards page with examples of the jQuery conventions.
Implementing these standards will need to be done in pieces. Much of our code is pretty close, but JSHint can’t even fully process some of the older files in our system due to the number of errors. We’d like to propose setting up some JSHint Compliance sprints to work through the codebase in a structured way.
Please leave a comment below if you would like to be involved in this process! Based on a quick poll of known interested parties we will be meeting in IRC Internet Relay Chat, a network where users can have conversations online. IRC channels are used widely by open source projects, and by WordPress. The primary WordPress channels are #wordpress and #wordpress-dev, on irc.freenode.net. tomorrow on November 6, 2013 19:00 UTC, where we can continue the conversation and brainstorm how best to break up the work.
#coding-style, #javascript