For the uninitiated, coding standards are the nerdiest sets of nerd rules that nerds like me tend to nerd out on. Seriously, there’s almost nothing nerdier in web development than coding standards, and even people who preach Linux operating systems and split keyboards can rest assured that they’re not sitting at the top of the nerd mountain on this one.
Personally, I love coding standards. I don’t know what it is about some reliably well-formatted code, but I genuinely feel myself cringing when I have to look at code with random indentation or funky variable names. It could be my background as an English teacher – I did spend too much time absorbed in grammar, punctuation, oxford commas, and diagramming sentences. Or maybe it’s just a specific place on the spectrum of obsessive-compulsive behaviors, in-between washing your car biweekly and making sure you completely tear the dangling plastic from the top of resealable food packaging.
When you first start learning to code, it’s great that everything is extremely binary. Either your code “works” or it doesn’t. Either it compiles, executes, and converts the “foo” to a “bar”, or it doesn’t. Very satisfying. But as your skills and projects scale, it becomes less about whether your code works and more about whether your code is better than it could otherwise be. Choices become more vague, a series of trade-offs. It becomes harder to figure out which solution is better than another, and you start digging into the minutia of specific decisions. In this view, coding standards are simply an arbitrary set of preferences that crystallize into rules.
Explaining WordPress Coding Standards
One example benefit of using coding standards is version control. When two developers both push code changes to a repository, you may want to see their respective changes visually. If both developers don’t follow the same coding standards, it adds a ton of noise to the visual difference display, and it makes it hard to focus on what was actually changed in the code. Of course there are plenty of other reasons for coding standards, but this is just one example of how they can make collaboration easier.
These days, code editors like VSCode can easily integrate with linting tools that will help you ensure that your code is following these standards. They offer advice on where your code is going wrong and will even auto-format sloppier code for you, if you’d like. That being said, not every WordPress user HAS to follow coding standards. If you’re just building custom websites or bespoke plugins for clients, you don’t need to worry about following the WPCS.
Personally, I recommend having at least some sort of coding standard set up in your editor, just for the clarity they provide. And if you’re going to have standards – and you may one day consider contributing to WordPress or publishing a theme or plugin – then you should consider using the WPCS as a starting point.
Coding Standards Lead To Anger, Anger Leads to Hate
Two big discussions in WordPress recently have focused on coding standards, and they’re great case studies in how these seemingly minor decisions have major impacts and implications on the project.
First, there was an earlier proposal of removing the infamous “Yoda Conditions” from the PHP standards. What are Yoda conditions? Basically, the Yoda condition rule says that when you do a comparison using equals signs:
if ( 'MasterWP' === $best_newsletter ) // Nice Yoda condition!Code language: PHP (php)
any variable must come after any constants, literals, functions, etc. The main goal is to prevent you from accidentally assigning a variable inside your condition, like this:
if ( $best_newsletter = 'MasterWP' ) // Functional, but bad code.Code language: PHP (php)
The main reason I’m breaking this particular example down is to show how arbitrary it actually is. Now, I’ll be honest with you, I’ve grown fond of Yoda conditions. Even if they do slow me down sometimes, they’ve become a part of how I write. I even read them in a Yoda voice in my head.
That being said, I can see how they don’t really do anything and could probably be a barrier for new contributors. They achieve the “prevent users from making mistakes” goal while completely missing the “making code more readable” goal. There’s a massive comment thread arguing the pros and cons, but I’m not here to rehash that conversation.
The point is that the proposal has been denied by Core Team member Peter Wilson in favor of maintaining the status quo. Again – I’m not really interested in the decision itself but am curious how the decision was made and finalized. When a proposal is submitted, what does the full process look like? Is the entire conversation just what exists in the comments on the Make block or are there Slack conversations that might be relevant to peruse? Did the original author of the proposal know who the final decision-maker would be?
I’m not making nefarious insinuations, I’m genuinely asking (as is the author of the original issue on Github). It seems like the biggest sticking point for the proposal was the amount of work involved, but many Yoda condition-haters seemed very eager to put in the man-hours necessary to rid WordPress of Yoda conditions once and for all. What seems clear is that most commenters were against Yoda conditions on principal. Is the dark side clouding our judgement here?
Yoda conditions are one of many barriers to entry for new WordPress developers (albeit a small one). Where do we rank “making WordPress contribution easier” on the massive list of project priorities?
Check Your Plugin (before you wreck your plugin)
The other big coding standards proposal, this time from the performance team, is to build a new plugin checker tool to confirm that plugin developers are following the WordPress Coding Standards. This proposal is still in discussion, but the biggest controversy seems to be whether this new tool will be used to unfairly punish developers who use a different coding standard (either out of preference or sometimes out of necessity).
If the tool is meant to help, but not used to hinder developers from submitting plugins, I think it’s a great idea. If plugin developers want to run tests on their own code, that’s awesome. If we’re going to run this against every plugin in the repo and report the results in WordPress somewhere, I’m not sure I would be so eager to support it. At this point, it’s unclear what the ultimate use of this plugin would be.
Update: After publication of the article, the original proposal author commented to mean that they would be focusing on standards relating “to security, performance, other functional best practices, not at all code style.“
The reason I bring both of these seemingly unrelated proposals up is because – again – I love coding standards, probably because I have what is considered a tight mindset in my adherence to social norms. I like structure and readability, and I like being on the same page with other people. In my earlier metaphor, I said that coding standards are a “dialect” or a strict variant of a general language. At a certain point, jumping into a codebase with opaque rules and guidelines feels like trying to understand Brad Pitt’s character in the film Snatch.
But I also know that sometimes rules don’t do anything but preserve the status quo and create an in-group feeling. Many rules actually just make it even harder to for new contributors to jump into a project, especially when the rules and standards are so idiosyncratic as to be punitive. Many early contributors are afraid of submitting patches for fear of being called out for something as minor as a “grammar mistake.”
WordPress cannot be afraid of making massive changes, especially changes that veer outside of the four sacred pillars of Gutenberg-ianity. And we must only use rules and guidelines that ultimately serve our goal of democratizing publishing, which sometimes means granting a little freedom and chaos where we’d otherwise prefer the strict order we’ve already grown accustomed to.