Although defined according to formal grammar and syntax, programming languages -- like their spoken counterparts -- often leave their users with a great deal of leeway for creative expression. For instance, the PHP language does not enforce syntactical rules such as whether a variable or function name must be capitalized, nor does it demand exacting placement of curly braces around statement blocks. This lack of enforcement means that the following two examples are identical in the PHP parser's eyes:
function salesTax($price, $tax) {
  return $price + $price * $tax;
function SalesTax($Price, $Tax)
  RETURN $Price + $Price * $Tax;
Yet taking such creative liberties with your code can ultimately prove a hindrance to anyone who reviews or even at some later point maintains your code. It can even be singularly counterproductive if you do not maintain stylistic consistency across projects, as you'll need to continuously re-acclimate to differing syntactical variations.
To help combat this problem within the PHP community, the PEAR team long ago devised a set of coding standards (known as the PEAR Coding Standards), which PEAR package developers must follow. Over the years, the specifications set out in the PEAR Coding Standards have been widely adopted across the entire PHP community thanks to its no-nonsense set of guidelines for indentation, variables, class definitions, comments, and control structures.
I've used the PEAR Coding Standards for years and have come to appreciate not only the consistency that their application brings to my code, but also the ability to point colleagues to a community-driven set of guidelines for team-driven projects. Incidentally, applying the PEAR Coding Standard to the above SalesTax() function would result in a definition like this:
function salesTax($price, $tax)
    return $price + $price * $tax;
However, in light of PHP's considerable expressive flexibility, how can you actively enforce a coding standard and prevent both yourself and your team members from reverting to bad habits? One great solution called PHP_CodeSniffer is (coincidentally) found in a PEAR package. PHP_CodeSniffer can not only parse PHP code to ensure it meets a particular coding standard but it can also examine your JavaScript and CSS files for potential standards violations.

Introducing PHP_CodeSniffer

Because PHP_CodeSniffer is a PEAR package, you can install it using the PEAR package manager if PEAR is installed on your local system (it probably is):
%>pear install PHP_CodeSniffer
When PHP_CodeSniffer is installed, you will have a command-line interface named phpcs at your disposal. You can peruse its help file by passing it the --help option:
%>phpcs --help

Validating a PHP Script

Although you can define your own coding standards and use them in conjunction with PHP_CodeSniffer, chances are one of the standards bundled with the package will be useful for you. These include MySource, PEAR (the default), PHPCS, Squiz and Zend. Therefore, to determine how well a particular PHP script conforms to the PEAR Coding Standard, all you need to do is pass the name (and potentially the path) of the script to phpcs:
%>phpcs AboutController.php
Depending on how well your script conforms, you may see any number of returned errors. As an example, I've purposefully added several mistakes to this AboutController.php script, producing the output presented below:
  2 | ERROR   | Missing file doc comment
  3 | ERROR   | Extra newline found before class comment short description
  4 | ERROR   | There must be exactly one blank line before the tags in class
    |         | comments
  4 | ERROR   | Content of the @author tag must be in the form "Display Name
    |         | <>"
  6 | ERROR   | Missing @category tag in class comment
  6 | ERROR   | Missing @package tag in class comment
  6 | ERROR   | Missing @license tag in class comment
  6 | ERROR   | Missing @link tag in class comment
 10 | ERROR   | Missing function doc comment
 15 | ERROR   | Function doc comment is empty
 25 | ERROR   | Function doc comment is empty
 30 | ERROR   | Public method name "AboutController::ContactAction" is not in
    |         | camel caps format
 41 | WARNING | Line exceeds 85 characters; contains 97 characters
 47 | WARNING | Line exceeds 85 characters; contains 133 characters
 59 | ERROR   | Function doc comment is empty
Obviously, using this output as a guide, you can iteratively fix the errors and rerun the phpcs command until the script is acceptable.
To validate an entire directory of scripts, you can pass phpcs the directory path:
%>phpcs /var/www/

Testing JavaScript and CSS Files

You can also use PHP_CodeSniffer to examine your JavaScript and CSS files. In particular, the Squiz coding standard (bundled with PHP_CodeSniffer) can be incredibly useful for examining these files, as it uses JSLint for examining JavaScript files and performs a number of useful CSS validations, such as determining whether a particular style is defined more than once.
For instance, to use Squiz when validating a file, pass along the --standard option:
%>phpcs --standard=Squiz styles.css


Over the years I've introduced a number of tools which can make your life as a developer much easier, among them Git, PHPDocumentor and PHPUnit. With PHP_CodeSniffer added to your workbench, you'll have another powerful tool capable of ensuring your code meets team guidelines, which will in turn improve the productivity of all involved.

About the Author

Jason Gilmore is the founder of the publishing and consulting firm He also is the author of several popular books, including "Easy PHP Websites with the Zend Framework", "Easy PayPal with PHP", and "Beginning PHP and MySQL, Fourth Edition". Follow him on Twitter at @wjgilmore.