It probably gets a bit tiresome to talk about coding standards, practices, and things like that when you’re trying to focus on simply getting things done.
And though I get it, I also think that having standards and practices – at least within the context of your team – can go a long way regarding being productive, writing maintainable code, and having things in place to help with maintenance over time.
All of that’s beside the point, though. In the last few years, I’ve found that WordPress – at least those who work on the server-side – usually come in two flavors:
- Those who follow the WordPress Coding Standards,
- Those who follow the PSRs.
I think there are good reasons for choosing either one. Naturally, I’d say that because I’ve almost always used the WordPress Coding Standards (I have very few exceptions), but I understand the choice to use the alternative as well.
And it’s something I’m beginning to consider doing, too. But I’m curious, for anyone who’s used both or who has an opinion (strong or otherwise) on which one and why to share.
PSRs or WordPress Coding Standards?
For those who are curious, I think the arguments on either side of these standards usually go something like this:
- I use the WordPress Coding Standards because I’m building a solution on top of WordPress. Since it, as a platform, as its set of rules, then I opt to use those rules, so others who come along to look at it or even maintain it can use the set of rules they [should] already know. Further, the WordPress rules are dated in comparison to what’s available now.
- I use the PSRs because the WordPress Coding Standards only apply to code that is going into core. WordPress’ rules are years behind what the rest of the PHP community is doing. And using the PSRs will yield greater understanding by a wider variety of people and allow us to leverage newer features of PHP.
I’ve likely oversimplified some of the arguments, but I’m trying to hit the high points more than anything else.
So if you’re a professional WordPress developer – be it someone who makes a living off of WordPress or not – I’m curious on your take and why you’ve opted to choose the particular group of standards.
Hey Tom,
I actually use both, in a more or less consistent way. I’ll try to explain through an example.
Let’s say you want to integrate your CRM into WordPress, by providing a list of clients, and showing dashboard widgets.
To provide such functionality, I split it up into the general-purpose PHP code and the WordPress-specific integration bits.
The general-purpose PHP code contains the code to connect to the CRM API, retrieve its elements, parse the data and shape it into the needed form, render HTML output, etc… For this, I use PSR-2 coding style, and I wrap it into a reusable Composer package. It is a library that I can use in several projects if I want.
The WordPress-specific integration contains the code to initialize the previously built library, and hook it up to the WordPress actions and filters, or wrap the HTML rendering into a shortcode or widget. For this, I use WPCS.
As there’s a clear separation (these being two completely independent packages), I can properly set them up in these two conflicting ways, automate the linting, etc…
However, even within WPCS, I absolutely refuse to use the WordPress file naming convention for classes. To me, classes are not an exception, they don’t need to be specially marked. All my logic is in classes, and they are named using the PSR-4 guidelines.
Cheers,
Alain
I just follow you.
hehe, that’s true, but it’s also what I was doing before I started following you.
I’m way more familiar with WPCS and it’s what I use by default and try to enforce internally at 9seeds. There are exceptions.
I’d honestly have no problem with adopting PSR on specific projects the way Alain suggests though. I think having, declaring and following a standard within a code set (and I mean core vs theme vs plugin, not “all the things”) is more important than what that standard is.
I’m also very in favor of updating WPCS to follow or at least better mesh with PSRs. Refactoring for a code standard change doesn’t seem so onerous. Maybe that can happen in conjunction with dropping PHP 5.2 support… because some day we have to drop back compat and move forward.
Switching back and forth depending on the project context gets confusing at times but I think it’s something that’s worth doing.
A New York Times editor wouldn’t accept a piece written in the house style of The Guardian. It’d confuse their readers. The same would apply to the WordPress code base (including the plugin ecosystem) and WordPress developers.
Funnily enough I’ve been considering the opposite. Right now our internal coding standards are a slightly modified version of PSR – at least partly because I wrote them having come to WordPress after a number of years of working with PHP in other contexts.
However because everything we do is WordPress I’ve been looking at the possibility of bringing our standards more in line with WPCS. Part of the reason for this is that while we haven’t published any of the plugins we’ve developed in-house on WP.org yet, we intend to at some point. And I’ve been told that in order to do so they should follow WPCS – though a quick look at the info on the WP.org plugins site doesn’t seem to make any mention of it.
I’m hesitant to make the change though, partly because as you said PSR is much more up-to-date and more widely used in the PHP community. And partly because I think code which follows WPCS just looks ugly with so many spaces everywhere!
Here at Event Espresso, we started off by following the WP coding standards for all the code we produced. However recently, we’re transitioning over to use PSR. One reason for this is because we’re finding that more and more developers from outside the WP community are starting to interact with our code and we want to make it easier to encourage this with something they are already familiar with (especially when it comes to IDE setup/code sniffing etc that they may already have in place).
There is definitely a challenge transitioning our codebase but in the long run I think it will work better for our codebase.
With that said, on our saas platform, since we still interact with a lot of WP work outside of our direct control (third party plugins/themes etc) we follow WP code standards for any development we do on those things.
I think coding standards should be project specific and consistent across all of the projects being developed by an individual or organization.
I tend to write under the WPCS (since most of my projects are WordPress related) with some minor discrepancies; nothing really noticeable just some added whitespace for my “readability” preferences.
Would PSR be better than WPCS? Perhaps an unresolvable debate but for the most part it really comes down to a choice. Whether an individual chooses a specific standard to follow or an organization’s code architect chooses a specific standard to follow the key is choosing the standard and consistently following it.
For organizations, I would also recommend stating (publicly or privately) what standard is to be used and have it taken into consideration with QA and testing; for individuals, staying with a consistent specific standard, or even a hybrid merging of multiple standards is always going to be better than not following any standards.
In the long run, with a known standard at the code’s core, any project will be better, more easily managed, and maintained by leveraging the consistency following a standard will provide.
I make an effort to use PSR, for everything. I can set the code formatting in Netbeans to follow PSR, then:
I write code, press ctl+shift+f and Netbeans applies formatting and I repeat the process.
Formatting code manually is a waste of time and a pain.
I use WPCS, with one exception. I use PSR-4 autoloading and file naming, and have the following in my .codeclimate.yml:
`
phpcodesniffer:
enabled: true
config:
standard: “WordPress-Core”
Conflict with PSR-4
exclude: “WordPress.Files.FileName.UnderscoresNotAllowed”
`
I use WPCS when developing to WordPress.
Just that, because any WordPress developer should understand my code.
I tend to favor this approach.