Ever been sick and go out only to see someone and the first thing you say is "Sorry, I don't want to shake your hand because I've got a bit of a cold"? Well you should feel the same thing with your code before sharing it with the world if you have no validated it with a coding standard.
Since my focus is on WordPress and for this post I'm referring more specifically to the WordPress Coding Standards. By the end of this post you'll have Atom automatically validating your PHP code using PHP CodeSniffer with WordPress Coding Standards in Atom.
[Tweet "When you share code it's expected to be of a certain quality. We want it to be high quality code."]
Why do we care?
When you share code it's expected to be of a certain quality. We want it to be high quality code. However the only way to be certain on that is through an effective practice of validation through coding standards.
Before I get to deep into it, what does "high quality" mean? PHP is PHP, right? Not entirely correct. Sure you can write PHP so that it runs and goes through error and warning free to display whatever it is that you want on the screen. Since WordPress is open source there are many people who contribute to the project. Which means everyone has a different style to their code. Some like spaces instead of tabs for indentation. Some like use shorthand PHP tags (don't do this please). Some don't like using spaces after commas. These are all preferences of the developer who is writing the code.
When a project has many developers with different styles, then the code becomes cumbersome, hard to read, and starts to degrade in quality if there are no coding standards in place.
To help with these sorts of varying "preferences" is a code sniffer, specifically the PHP CodeSniffer.
If you were to look into the core files, you would see a uniformity amongst the code. This is due strict adherence to the WordPress Coding Standards. When we create themes or plugins, we should also follow these guidelines. This ensures that should someone else need to use our code, we are spreading the best practices of coding WordPress.
I will be the first to admit that I haven't always done this. Especially in times of high pressure. However after working with some larger teams over the years, I've realized the great importance to adhering to the WordPress Coding Standards. It not only looks better and easier to read, but it saves enormous amounts of time when you share code, review code, and run tests on your code.
PHP CodeSniffer With WordPress Coding Standards in ATOM is the cure
PHP CodeSniffer is used to detect violations of a defined set of coding standards. The set of standards is in the form of XML. This can be run any number of ways over code, but for this post I want to show you how to implement PHP CodeSniffer with WordPress Coding Standards and Atom.
Atom is my code editor of choice. What I like about it is the speed of it, but it's coupled closely with Github which I use for all my projects. Integrating the PHP CodeSniffer with the WordPress Coding Standards into Atom isn't hard at all. It takes only a matter of a few minutes and you've already leveled up your development by doing so.
1. Install PHP CodeSniffer
With a few simple commands, we are going to install the PHP CodeSniffer project and the WordPress Coding Standards
[wpgist id="cb4b1c681ae06e936996" file="CLI.sh"]
Since I'm on a Mac, I'm going to install PHP CodeSniffer with Homebrew (if you aren't using that, check it out). That's the first command we want to run. If you aren't on a Mac or use Homebrew, you can just clone the repository directly, then add the phpcs binary to your path. These are lines 1-3 in the snippet above.
You can run phpcs on a file via the command line and it'll validate the PHP code on that file.
2. Install and Setup WordPress Coding Standards
Next we want to install and setup the WordPress Coding Standards. This is so that when we run PHP CodeSniffer on some files, it can validate the WordPress Coding Standards rules.
Lines 4-5 will clone the repository to a directory called wpcs.
Once that's finished, we need to link the ruleset to the PHP CodeSniffer. To do that is fairly simple. First run phpcs -i (Line 9) and you'll see the rulesets it currently has loaded. It should be something like this.
$ phpcs -i$ The installed coding standards are MySource, PEAR, PHPCS, PSR1, PSR2, Squiz, Zend
Once that's coming back to you, run Line 10. Be sure to replace <path to dir that you cloned> with where you cloned the wpcs directory to.
If you run phpcs -i once again, you should see
$ The installed coding standards are MySource, PEAR, PHPCS, PSR1, PSR2, Squiz, Zend, WordPress, WordPress-Core, WordPress-Docs, WordPress-Extra and WordPress-VIP
So now that we've got PHP CodeSniffer working and using the WordPress Coding Standards, let's configure Atom.
3. Configure Atom to Use PHP Codesniffer
The first step is to install the package linter-phpcs, unless you have this installed already.
After that's been installed, then it's just a matter of configuration for the WordPress Coding Standards ruleset. Open up your config.json file inside of Atom by going to the menu Atom > Open Your Config and then find the linter-phpcs block. If you do not have one, then you can add it to the bottom.
My config looks like
[wpgist id="cb4b1c681ae06e936996" file="config.json"]
Most of it is pretty self-explanatory however the key value here is the codeStandardOrConfigFile. You can select which ruleset you want to use. By choosing WordPress, it will be the complete set of rules. You may not need the VIP ruleset, but for me, there's no reason to not include it in case your code ends up on VIP even if you aren't.
VALIDATE ALL THE THINGS AUTOMATICALLY!!
Once that's been setup, close out of Atom and then open it back up. If you have set it up properly you'll notice on the bottom in your status bar a new section pertaining to the errors and warnings in the open files. It will look something like
http://rezzz.com/wp-content/uploads/2016/01/testing-codesniffer-1.png
You'll have a notice in next to the line numbers as well as the bottom of the screen. Red is an error and Yellow are just warnings.
The best part is that after you adhere to the errors and warnings, you'll see "No Errors" with a check in green at the bottom.
http://rezzz.com/wp-content/uploads/2016/01/all-passed.png
My best suggestion is to tidy up as you write code, rather than write code and then go back to clean it up. By doing that, you'll get practice in writing according to the standards and ultimately save you time in the long run.
Now go forth and feel better about sharing your code knowing that you won't be sharing any germs with the world.
