PHP_CodeSniffer

We've just put together our development plan for PHP_CodeSniffer 1.3.0 and it contains some great features that are going to make it dead-simple to customise the built-in standards without having to write any PHP code. The biggest change is the ... [More] concept of violation codes for sniffs. Currently, each sniff can throw different errors and warnings using different error messages, but there is no way to target each of them. Sniffs can now specify violation codes so each of those errors and warnings can be uniquely identified within PHP_CodeSniffer. We'll be adding violation codes for all sniffs that ship with PHP_CodeSniffer. For developers who have written their own sniffs, you can start testing violation codes now as this feature has just been committed to the PHP_CodeSniffer SVN repository. To add a violation code, you simply specify a third argument to the addError() and addWarning() methods: $error = 'Line exceeds maximum length of 85 characters'; $phpcsFile->addError($error, $stackPtr, 'LineTooLong');  The goal of the violation code development is to make it easy for developers to customise the messages and severities of errors and warnings. You will be able to do this via a ruleset.xml file (similiar to this one) where you can customise as much or as little of a standard as you want. You'll be able to translate messages into other languages, add more useful information into the messages for your team, turns errors into warnings, turn warnings into errors and even remove errors and warnings from the standard all together. And all this via a simple XML file. Severities are also something we are working on. Currently, PHP_CodeSniffer only has two severity levels; error and warning. We are going to maintain these two different types of messages but add severity levels to them. So instead of having just 5 errors and 2 warnings, you might have 1 severity 10 error, 4 severity 4 errors and 2 severity 7 warnings. You can use the error and warning categories to decide between issues that must be fixed and issues they should be looked at, but then go a step further and decide on a severity to help you prioritise reviews. All these severities will be set in the ruleset.xml file, so sniff developers don't need to do anything if they are happy with the default values we will provide when adding errors and warnings. All reports will get an option to filter errors and warnings by a severity level that you define. Once we have all this going, the next logical step we are looking at is to allow this ruleset.xml file to define parameters for sniffs. The line length sniff is a great example of where this would be useful. You may be using the PEAR standard, so you will see warnings for all lines over 85 characters in length. With this new feature, you could add a line into the ruleset.xml file so that when you run the PEAR standard you would only see warnings for lines longer than 95 characters. Previously, you had to write your own standard and custom sniff to override the protected member var of the PEAR sniff. With this feature, it will be as easy as an XML tag. Lastly, we are restructuring the reporting system to remove all the report code out of CodeSniffer.php and put it into separate classes. This not only cleans the code up a bit and ensures we don't load any code we don't need, but it will also make it possible for you to write custom reports for to help you integrate PHP_CodeSniffer with other applications in your development and integration environments. So that's an awful lot of development headed for PHP_CodeSniffer. Some of the smaller changes will roll out in the 1.2.x releases for developer testing, but most will not be available until a 1.3.0beta1 release sometime early next year. We'll keep you posted. [Less]

PHP_CodeSniffer version 1.2.1 has just been uploaded to PEAR and is now available to install. It's been exactly 3 months since the 1.2.0 release and plenty of changes have made it into this version, including a few new features as well. Some ... [More] of the highlights are: A new report type called svnblame that allows you to see which developers are causing the most errors The ability to set the report width for all reports, which is really useful for developers with larger screens The addition of @codingStandardsIgnore comments to tell PHP_CodeSniffer to ignore parts of a file or the entire file There have also been some great changes made to the CSS and JavaScript tokenizers to improve their stability. All new features have been fully documented and are available on the PHP_CodeSniffer documentation page. You can view the full changelog on the PHP_CodeSniffer download page. [Less]