PHP_CodeSniffer Article in php|architect

The April 2011 issue of php|architect Magazine was published today and includes an article by me entitled “Keeping Code Smelling Pretty With PHP_CodeSniffer.” Feel free to leave a comment on this blog post if you read it and enjoy it or have a suggestion on how to improve my presentation of the material. Thanks in advance!


  1. When I downloaded the April issue of php|architect today, I jumped right to your article on PHP_CodeSniffer. I’ve just started trying to enforce standards with a remote team, so the timing was perfect. I definitely learned quite a bit more about the internals of how it works, which was much appreciated.

    One question I had was why a team or company might decide to create their own standard instead of leveraging one of the more widely used standards included with the tool? I’ve decided to go with the Zend standard since the vast majority of our projects used Zend Framework and it seemed like a natural fit. While I don’t like all of the decisions they’ve made in the coding standard, I still felt a bit more comfortable picking a standard that was widely used. Part of my thought was that as we add team members, there’s a likelihood they may at least be familiar with this standard.

    I’d love to hear your thoughts on this topic. Thanks again for the article.

  2. @Joel I don’t know if I mentioned this in my article, but to my knowledge, the Zend standard bundled with PHPCS is *not* the same as the Zend Framework standard. The only effort I know of to implement a PHPCS standard for ZF is being done by Ben Scholzen (AKA DASPRID), is for ZF2 specifically (I don’t know if there are any differences between the standards for ZF1 and ZF2), and is housed on github here: As far as choosing an existing coding standard versus creating a new one, there are a few advantages to going with an existing one:

    1) Existing standards are likely to have existing tools (like a PHPCS standard) to help you maintain conformance.
    2) The decisions involved in creating a new standard are prime targets for bikeshedding. Using an existing one minimizes decisions you have to make, usually just instances where you want to veer from or supplement the standard.
    3) If you’re basing your code on an existing project like ZF, it makes your code consistent with that code. While you may never submit a patch to ZF, if you do, you won’t find it being rejected for not conforming to the standard.