Title: Proposal for JS Standards Revision: Removing Array/Function Whitespace Exceptions Author: Andrew Duthie Published: September 7, 2017 --- [ ](https://profiles.wordpress.org/aduth/) [Andrew Duthie](https://profiles.wordpress.org/aduth/) 1:02 pm _on_ September 7, 2017 Tags: [javascript ( 130 )](https://make.wordpress.org/core/tag/javascript/), [standards ( 5 )](https://make.wordpress.org/core/tag/standards/)    # Proposal for JS Standards Revision: Removing Array/Function Whitespace Exceptions Coding standards have been a recurring topic in the [JavaScript Weekly Chat](https://make.wordpress.org/meetings/) over the past few months. One rule in particular which has been the focus of much discussion are the [exceptions for whitespace in arrays and function calls](https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/#arrays-and-function-calls), which reads: > Always include extra spaces around elements and arguments: > […] > Exceptions: > * […] do not include a space around string literals or integers used as key values > in array notation > * Function with a callback, object, or array as the sole argument: No space on > either side of the argument > * Function with a callback, object, or array as the first argument: No space > before the first argument > * Function with a callback, object, or array as the last argument: No space after > after the last argument In the course of our chats, there has been some consensus around removing this “ Exceptions” section entirely, though we considered to seek broader feedback on the decision, particularly in how it impacts overlapping PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher standards and existing code. **Why should this exception be removed?** The purpose of a coding standard should be to impose sensible rules for the sake of consistency and readability. In the case of consistency, a developer should be at ease both in writing and reading code. The very existence of an exception is at odds with these ideals, harming consistency in that: * A code reader may not think to expect it if they are not familiar with the exception * A code writer may not know to apply it if they are not familiar with the exception. Or worse yet, one familiar with the rule may not know _how_ to apply it. The arrays and functions exception is notably egregious for being difficult to apply. Take, for example, the following snippet of code: ``` ( function( wp ) { wp.foo = foo( 5, {}); wp.bar(function() { console.log( 'Done' ); }); wp.baz( x, x + 5 ); wp.baz(x => x + 5); } )( window.wp = window.wp || {} ); ``` This code is valid in its use of whitespace, but took considerable effort on the part of a developer well-versed in the standards to understand precisely where the exceptions do and do not apply. Generally, exceptions increase the barrier to entry for new developers by imposing another prerequisite to becoming productive, increase overhead for existing contributors by requiring careful consideration of their application, and are anti-productive in the review hours wasted enforcing their inevitable mis-use. **Why should this exception not be removed?** All of the above notwithstanding, the exceptions concerning array or object keys at least have some basis in overlap with [equivalent rules in the PHP Coding Standards](https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/#space-usage). While I would argue that most all exceptions should be avoided, the focus of the first section is aimed primarily at function arguments, which tends to cause most uncertainty. It may be an agreeable compromise to remove only the exceptions impacting function arguments, leaving still the array and object key exceptions. Standards changes should be carefully considered, as it has a large impact on existing code which applies the current standard, and on knowledge of developers who have already become familiar with the standards. However, my experience is that these exceptions aren’t particularly well-understood, and in-fact that eliminating them would be more in spirit with how whitespace is otherwise applied ([_“When in doubt, space it out.”_](https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/#spacing)). **What happens next if these exceptions are removed?** If consensus is reached, the following actions should be taken: * Our standards documentation are updated to remove the exception language * Our ESLint rules are updated to remove the exception * All new commits to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. follow the new standards * Old code will only be refactored as part of a larger, codebase wide refactoring effort (see related effort at [#41057](https://core.trac.wordpress.org/ticket/41057)) _What are your thoughts? Please share in the comments below._ [#javascript](https://make.wordpress.org/core/tag/javascript/), [#standards](https://make.wordpress.org/core/tag/standards/) ### Share this: * [ Threads ](https://make.wordpress.org/core/2017/09/07/proposal-for-js-standards-revision-removing-array-function-whitespace-exceptions/?share=threads) * [ Mastodon ](https://make.wordpress.org/core/2017/09/07/proposal-for-js-standards-revision-removing-array-function-whitespace-exceptions/?share=mastodon) * [ Bluesky ](https://make.wordpress.org/core/2017/09/07/proposal-for-js-standards-revision-removing-array-function-whitespace-exceptions/?share=bluesky) * [ X ](https://make.wordpress.org/core/2017/09/07/proposal-for-js-standards-revision-removing-array-function-whitespace-exceptions/?share=x) * [ Facebook ](https://make.wordpress.org/core/2017/09/07/proposal-for-js-standards-revision-removing-array-function-whitespace-exceptions/?share=facebook) * [ LinkedIn ](https://make.wordpress.org/core/2017/09/07/proposal-for-js-standards-revision-removing-array-function-whitespace-exceptions/?share=linkedin) 1. ![](https://secure.gravatar.com/avatar/73c1045212929211deda7262005831319397c68d340a8c41d53633b3f7e7f129? s=32&d=mm&r=g) 2. [Andrew Ozz](https://profiles.wordpress.org/azaozz/) 1:41 pm _on_ September 7, 2017 3. “Heavy plus one” for removing the function arguments exceptions from the JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. coding standards (in the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher coding standards there is always a space around the arguments). 4. It also would be nice to standardize arrays and objects, for both JS and PHP. I don’t see a good reason why there should be spaces around variables but not around strings or numbers. Both seem equally “readable” which is the most important part 🙂 5. ![](https://secure.gravatar.com/avatar/7ad325c24fa7c21069444a3fb9a809ee2ce5e176ef834eab25f87d550569ce0a? s=32&d=mm&r=g) 6. [Nikola Nikolov](https://profiles.wordpress.org/nikolovtmw/) 1:48 pm _on_ September 7, 2017 7. Yes, please! It’s been so frustrating that the JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. standards has that exception and is different than the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher standard that I usually ignore it( 😁 ). 8. Having as similar(or the same if possible) of a standard between PHP and JS is crucial in my opinion. Especially now that the focus is somewhat shifting to JS, you’re going to have a lot more developers that were used to writing mostly PHP jump into the JS world and be confused about the standards. 9. ![](https://secure.gravatar.com/avatar/7d4e6978df89809d15df65aac619677de2180d4e0ec5a613aece7c9e7103324d? s=32&d=mm&r=g) 10. [J.D. Grimes](https://profiles.wordpress.org/jdgrimes/) 4:12 pm _on_ September 7, 2017 11. +100 for removing the function argument exceptions. 12. For the array and object spacing, in my opinion the existing rules make sense. No spacing for variables doesn’t seem right and isn’t as readable. For strings and integers though, I don’t think the spaces are necessary, and the code is actually less readable with spaces added, just because of the strangeness of the style. So I would be against removing the exceptions for string and integer array keys from either the JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. or PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher standards. 13. ![](https://secure.gravatar.com/avatar/120b2dbc332ea0daf46d432e7d1fd3bf9a2b98955f9bad07dfd3ff8eb0fdfc87? s=32&d=mm&r=g) 14. [Stephen Edgar](https://profiles.wordpress.org/netweb/) 12:57 am _on_ September 8, 2017 15. Thanks for writing this up [@aduth](https://profiles.wordpress.org/aduth/) 👍🏼 16. FYI: There is ticketticket Created for both bug reports and feature development on the bug tracker. [#31823 ](https://core.trac.wordpress.org/ticket/31823) to add ESLint support (replacing JSHint). Refactoring existing JavaScriptJavaScript 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](https://www.javascript.com/) will take place in this same ticket akin to PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher in [#41057](https://core.trac.wordpress.org/ticket/41057) 17. ![](https://secure.gravatar.com/avatar/70760a65c49683cfa79f9b9e6d59aab61aad23742a02bd0e25916dfc23fe347d? s=32&d=mm&r=g) 18. [Thorsten Frommen](https://profiles.wordpress.org/tfrommen/) 6:36 am _on_ September 8, 2017 19. I strongly support removing the function argument exceptions. 20. It’s just like you said: standards are there for good reasons, and thus exceptions need to have an even better reason to exist. All the mentioned no-space rules/ exceptions make not much sense, to be honest. Also, there is currently no way to make PhpStorm auto-format code according to these exceptions. So yes, let’s _space things out_. 🙂 21. Regarding the spacing of variables as keys vs. not spacing scalar keys, I don’t have a strong preference. Some time ago, this was, too, not possible with PhpStorm. But this changed, so you can follow the current standard here while autoformatting. 22. BTW, the (modern) [ESLint config](https://github.com/inpsyde/javascript/tree/master/packages/eslint-config-inpsyde) that I created for/at Inpsyde does **not** have the function argument exceptions, but it [adheres to the current array key spacing standard](https://github.com/inpsyde/javascript#spaces). Again, I’d be fine with all of the three: consistent with spaces, consistent without spaces, or space only non-scalar keys. 23. ![](https://secure.gravatar.com/avatar/120b2dbc332ea0daf46d432e7d1fd3bf9a2b98955f9bad07dfd3ff8eb0fdfc87? s=32&d=mm&r=g) 24. [Stephen Edgar](https://profiles.wordpress.org/netweb/) 11:01 am _on_ September 9, 2017 25. Via SlackSlack Slack is a Collaborative Group Chat Platform [https://slack.com/](https://slack.com/). The WordPress community has its own Slack Channel at [https://make.wordpress.org/chat/](https://make.wordpress.org/chat/) [https://wordpress.slack.com/archives/C5UNMSU4R/p1504619875000809](https://wordpress.slack.com/archives/C5UNMSU4R/p1504619875000809) 26. > azaozz: … actually thinking we should remove these exceptions from the php coding > standards too > azaozz: as far as I remember they are “left overs” from how the code was formatted….. > 10 years ago :slightly_smiling_face: 27. ![](https://secure.gravatar.com/avatar/63b496ec3806485229b4f934b26643dad6e734ca6e6ef7b38c846205b01cd37f? s=32&d=mm&r=g) 28. [Weston Ruter](https://profiles.wordpress.org/westonruter/) 6:19 pm _on_ September 11, 2017 29. I agree with removing the exceptions. 30. ![](https://secure.gravatar.com/avatar/fcaa91740ecb07b2653eb28d0d22a53d7880f16d30e2802e6dc1de8c83fca61f? s=32&d=mm&r=g) 31. [Mizner](https://profiles.wordpress.org/mizner/) 1:30 pm _on_ October 4, 2017 32. Throwing support on this 33. ![](https://secure.gravatar.com/avatar/3fc6118ca85395c670639f761bcbd6955eae63062af98ea235e00e917b2e8417? s=32&d=mm&r=g) 34. [herregroen](https://profiles.wordpress.org/herregroen/) 1:56 pm _on_ October 10, 2017 35. Completely agree with this proposal! 36. ![](https://secure.gravatar.com/avatar/f4226aad00975bb106756610d04b6bb3bd65027d37d1839dbd6c285f12c8a49d? s=32&d=mm&r=g) 37. [Andrew Duthie](https://profiles.wordpress.org/aduth/) 5:00 pm _on_ October 16, 2017 38. Based on complete consensus within this comment thread and [last week’s core-js meeting](https://wordpress.slack.com/archives/C5UNMSU4R/p1507643518000339), I have removed exceptions from the guidelines _specifically for function arguments_. 39. [https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/#arrays-and-function-calls](https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/#arrays-and-function-calls) 40. Because there was not consensus around array/object keys, I have left those for the time being, though my personal preference would be to remove them as well. This can be discussed further in future weekly JavaScriptJavaScript 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](https://www.javascript.com/) meetings. Comments are closed. # Post navigation [← Dev Chat Agenda for September 6th (4.9 week 6)](https://make.wordpress.org/core/2017/09/06/dev-chat-agenda-for-september-6th-4-9-week-6/) [Removing SWFUpload →](https://make.wordpress.org/core/2017/09/07/removing-swfupload/)