I didn’t make a big deal when it happened (I did have a very newborn baby, after all), but at the beginning of October I was promoted to Engineering Manager at 10up.
When I was offered the promotion, I immediately went to work trying to figure out what my personal goals as a manager would be. Some were obvious: support the engineers, promote the team’s accomplishments within the organization, and try to get everyone more comfortable with unit testing, but one area in particular that I felt would be a good area to focus was coding standards.
Anyone who’s had to do code reviews on a team before can tell you that inconsistent coding standards add a lot of unnecessary noise to the review process. Even minor things like trailing whitespace, spaces v. tabs, code indentation, and whitespace (or lack thereof) around function declarations can cause merge conflicts and increase the time it takes to do a good code review.
Fortunately, coding standards are pretty easy to check, and there are great tools like PHP_CodeSniffer that can scan your codebase for issues with coding standards. WordPress has a well-defined set of coding standards, and there’s even a collection of PHP_CodeSniffer standards for WordPress. With Composer and a little bit of configuration we can check our coding standards, catch common security issues (missing input sanitization, output escaping, etc.), and even validate that everything’s well-documented.
We have the tools to write standards-compliant code, so now we just have to configure them and make them run automatically. That’s where my latest project comes in: I’m happy to announce WP Enforcer is available for your projects!
How does it work?
WP Enforcer is installed as a Composer package in your project:
|
1 2 |
$ composer require stevegrunwell/wp-enforcer $ ./vendor/bin/wp-enforcer |
After we run the setup script, a pre-commit Git hook is installed in your local copy of the repository. From that point on, any file that you attempt to commit to the repository will automatically be checked against common WordPress coding standards.
As Git Hooks don’t get pushed to remote repositories (e.g. GitHub), you can add the following post-install/update commands to your composer.json file to automatically add Git Hooks for anyone who installs your project’s Composer dependencies:
|
1 2 3 4 5 6 |
{ "scripts": { "post-install-cmd": ["wp-enforcer"], "post-update-cmd": ["wp-enforcer"] } } |
If you’d like to customize the rules used for your project, you may also override individual rules by modifying the phpcs.xml file created by WP Enforcer according to PHP_CodeSniffer’s ruleset.xml standards. Ignore a certain directory? Easy! Writing code that needs to pass WordPress.com VIP’s more stringent rules? There’s a standard for that!
Thanks to WP Enforcer, you can easily enforce coding standards (and catch common coding errors) automatically, before they’re committed to the repository!
The source for WP Enforcer lives on GitHub and is open for contributions.
John P. Bloch
Composer pro-tip: ./vendor/bin/ gets popped on the beginning of $PATH so you can just add wp-enforcer as the post-install/update command. Awesome package!
Steve
I always get paranoid about this, but I suppose that would actually make it more portable (since you can change your vendor directory location). Just opened #3 on GitHub, will knock this out for the next version.
Thanks for the tip!
bswatson
Really looking forward to using this one a day-to-day basis. Hopefully it eliminates some of the unnecessary back and forth generated during code reviews for something as minor as an extra new line causing conflicts during a merge. Excellent work!
Tim Nolte
I’ve added PHPCode_Sniffer into my CI process and fail builds for it but I have had many failed builds because I forgot to check the WP coding standards before committing. This is going to be huge for me. For all of my personal plugin development I’m requiring WP Coding standards compliance. I also won’t accept pull requests that don’t pass the WP coding standards. Will this support reading a phpcs.xml.dist in my repo root? That’s how I’m managing my coding standards rules, and doing things like excluding composer vendor directory which I don’t want scanned for WP Coding standards.
Steve
Indeed! WP Enforcer was designed to be used as a Composer dependency with post-install-cmd hooks, ensuring that someone can’t (easily) install the Composer dependencies for the project without also getting a pre-commit hook thrown added (since Git hooks don’t ship with the repo). Additionally, it’ll only run PHP_CodeSniffer against the files that are being changed in a commit, which make it much easier if parts of your codebase are less-than-compliant.
When you first run WP Enforcer, a phpcs.xml file will be created (if one doesn’t already exist) with some sane defaults. Please let me know how it works out for you!