How much does your coding standard check?
28 JulOr maybe the title should be: How Annoying is PHP_CodeSniffer for you? or so the devs around here say. But should they be believed? Are they actually serious or just having a dig?
I've just finished adding error codes to all error and warning messages in PHP_CodeSniffer. This has now allowed me, for the first time, to really take a good look at just how many things each of the included standards are checking.
Obviously, the standards check for a wide range of different violations. Some are formatting issues. Some are performance issues. Most are a matter of preference, defined for the sake of having a standard that everyone in a diverse team can follow. The only differentiation that can be easily made is if something is serious enough to be considered an error, so that's what I'm working with.
The table below lists the complete standards that are included in PHP_CodeSniffer. The Zend and Generic standards are not listed because they are really more of a collection of tools rather than a complete and defined standard. Each standard in the table lists the number of discrete checks being made during a run and the percentage of those checks that produce errors instead of just warnings.
| Standard | Checks | Error % | Notes |
|---|---|---|---|
| PEAR |
132 |
94% |
The default standard and the one used for all PEAR packages. |
| Squiz |
465 |
93% |
The generic standard we use at Squiz Labs. |
| PHPCS |
414 |
94% |
The standard I use for PHPCS itself. Includes the whole PEAR standard plus some of the Squiz standard. |
| MySource |
484 |
94% |
The standard we use for MySource Mini. Includes the whole Squiz standard plus some extras. |
Interestingly, the error percentages for all the standards are about the same. So these coding standards have a few warnings, but the vast majority of their checks are considered important enough to throw errors. There is little room for variation. I personally like this in a standard. Standards that give you a few guidelines or provide you with ambiguous messages and not useful for a developer. If you can't check for it and provide an alternative syntax, save it for the formal code review process.
So how annoying is PHP_CodeSniffer for the developers working on MySource Mini? We are checking 484 different things each time they write a line of code in a PHP, CSS or JS file. So it must be really annoying!
But it's not that bad. You get used to it. You learn the standard and you naturally write code the way everyone has agreed. You make mistakes and they get picked up, but they are easy to find and easy to correct.
When used in this way, PHP_CodeSniffer is the educational tool it was designed to be. It was never intended for developers to be able to write code in whatever style they want and then run a tool to tell them how to make it conform. What a waste of developer time that would be.
As a developer, your job is to solve problems by writing code. The way you write it should be flexible enough that it can change between companies and projects. Hopefully PHP_CodeSniffer can help you learn a new style more easily than just reading a guide and let you know when you are drifting back to an old style.