Wednesday, 17 December 2008

Spurred on by some feature requests and at least one annoying colleague (you know who you are), I've made some fairly good improvements to the way PHP_CodeSniffer reports the errors and warnings it finds. I've added support for the concept of error sources, allowing you to see which sniff generated an error and also filter out the messages for that sniff.

The XML, CSV and CheckStyle report formats all now include a source attribute in their output. This will allow continuous integration platforms to call PHP_CodeSniffer and produce a report of the most common errors rather than just display a list of all errors or the number of errors for each file.

You can also expose this information in the full and summary reports, although it is off by default to avoid clutter. Use the new command line argument -s to show sources in these reports. Instead of something like this:

The idea with these source IDs is that you can then use them to filter your (potentially) long list of error messages and target a particular rule that you want to fix all in one go. So in this report, we have 3 errors generated from PEAR.WhiteSpace.ObjectOperatorIndent. To find out what they are, add the command line argument --sniffs=PEAR.WhiteSpace.ObjectOperatorIndent to get this:

Another related feature that was added is the ability to write the report output to a file in addition to writing it to the screen. This solves the problem where PHP_CodeSniffer comes across some code it cannot parse and throws PHP notices before XML output, creating invalid XML. Writing to a file is easy; just use the --report-file=filename command line argument.

All these features are currently in CVS and will be released in 1.2.0a1 very soon.

About Me

I'm the product development manager at Squiz Labs, managing the MySource Matrix and MySource Mini CMS development teams.I'm also the lead developer of a PEAR package called PHP_CodeSniffer, designed to check PHP code for violations of a defined coding standard.