The WP core, many WP plugins, and the WP coding standards themselves use a very “generous application” of the Space character (not for indentation, but “inside” of parens and brackets). This seems to be unique to WordPress – this style/philosophy does not seem to be present in other similar projects, PHP or otherwise.
For more information on this approach, see: https://make.wordpress.org/core/handbook/coding-standards/php/#space-usage
Example: foreach ( (array) $foo as $bar ) { ...
I’m referring to the space after foreach, after the first (, and before the final ) (and other similar spaces shown in “Space Usage” at the link above).
This style seems unnecessary to me – it requires more typing and (opinion)makes parsing code visually more difficult.(/opinion)
My desire is not to debate whether or not this style is a good idea. Rather, I simply want to understand the motives for why this is the recommended style. Even commenters on the WP coding standards are curious:
The answers provided to MK Safi’s question are essentially:
- For readability
- Status quo (aka “That’s just the way it is”)
My reasoning for asking is that I personally don’t see much value in adopting the WP coding standards (regarding “Space Usage”) in our internal-only projects. However, I’m curious if I’m missing something.
Are there any reasons beyond the two listed above, ostensibly valid or not, for following WordPress’ “Space Usage” style?
Resoning
Regarding “white space” (no matter if tabs or spaces): It’s simply a personal preference that stuck with the project.
The WP coding standards imo are a mess and can be ignored – as long as you aren’t contributing to core, which is
- a different story and
- style guide gets ignored there as well.
“[…] it isn’t retroactively applied in bulk on older code as it makes svn/git history very difficult to use. Official policy is that new code should follow the style guide, but if you happen to format adjacent code correctly then so be it, but patches that only format code, or commits that only format code are forbidden.”
– @TomJNowell in the comments
Alternatives
You are better off sticking with the PSR standards (namely: 2) or stuff like the Symfony standards (or just your own).
Performance Increase & Tools
There is no profit you gain from having a coding standard (aside from having one to share and the minority that hates it, while the rest dictates it) or from having more or less tabs or spaces. In case you are worried about unnecessary disk space used or maybe slower programs, you can still compress your code (see the GitPHPHooks project) on commit. The benefit you will gain will be around max 5% from the original file space, pretty much equal to what HTML syntax compression/minification gives you. There are Node.js minify tools available via npm for that.
What I personally really found to be helpful is the PHP Linter and the _PHP Mess Detector. I incorporated both into the GitPHPHooks Library so I don’t have to think or care about running it.