Did you know that WordPress itself has the WordPress Coding Standards (WPCS)?
There are three linters that go along with this you should consider using, and one that’s invaluable.
Having the WPCS PHP_CodeSniffer implemented for PHP linting purposes means that it will tell you:
- When you haven’t escaped something properly
- When you haven’t made text translation ready
- When you’re using a function that is not best practice for the WordPress platform
- When you’re not adhering to proper syntax
- And much more
It’s not all about the code just looking pretty. It can have significant security and performance benefits because let’s face it:
Nobody is perfect.
My favorite way to install this is with Composer as a dependency with a “.phpcs.xml” file to point to it in the root of your repository. You can then set which folders and/or files to ignore. You can even tie these linter commands into your CI pipelines to enforce that you have to either:
- Utilize best practices set forth by the WordPress platform; or
- Write a “phpcs:ignore” to document why you’re making an exception to the rule and why it doesn’t make sense to
You can even set permanent exceptions to the rules using your “.phpcs.xml” file.
This will allow you to follow the same CSS or SCSS format that WordPress follows.
@wordpress/eslint-plugin
This will allow you to follow the same JavaScript, TypeScript, and React format that WordPress follows. This also lints for certain common security issues, and translation issues.
Additional considerations
Again, opinionated – but I believe it’s best practice to use the coding standard that your CMS set forth. If the security, performance, and standardization reasons above aren’t convincing enough, here’s more:
- An increasing number of developers are familiar with the WPCS which makes hopping into your code easier and more predictable
- When debugging, sometimes you must browse through core or plugin code along the way to identifying bugs. This prevents having multiple syntaxes to look through which can be confusing and inconsistent.
- Sets you up for if you ever work with enterprise clients on WordPress VIP
When does it not make sense to use WPCS for syntax?
I think where you may or may not draw the line is if you’re working with a team of developers and work in different systems other than just WordPress. In that case, you may only want to have one coding standard, rather than expect your developers to know multiple coding standards (one for each system). You should still however, consider building on top of the WPCS PHPCS, and tweaking the .phpcs.xml file to meet your syntax standards while still retaining the ability to lint the code for best practice standards.
Bringing this approach to Adjacent
As I begin my new role here at Adjacent, some of the many duties I have been tasked with is advocating for new technologies, processes, and solutions as well as technical audits and documentation of recommendations. I strongly believe that this is a step in the right direction for all of us and — as such — will be making this a priority.
Here’s to creating a better web together!
