I uploaded the 1.1.0 stable release of PHP_CodeSniffer earlier this week. This version has been a long time coming, but does include a lot of changes. The most exciting (for me) is the ability to sniff JavaScript files and find coding standard errors within them.
We have been using this feature internally at Squiz for a few months to start cleaning up our JavaScript files and make them, as much as we can, conform to our PHP coding standards. This allows developers to move more freely between PHP and JavaScript code throughout the day.
The other great addition was contributed to me by Jake Bates and allows PHP_CodeSniffer to be used within an SVN pre-commit hook. This allows code that violates your coding standard to be blocked from your code repository; an extreme but sometimes necessary rule.
You can view the full changelog and download the release on the package download page.
Thursday, 17 July 2008
PHP_CodeSniffer 1.1.0 released
Subscribe to:
Post Comments (Atom)
I'm the product development manager at Squiz.net, managing the MySource Matrix CMS and MySource 4.0 development teams.
5 comments:
Hi,
I've recently upgraded my PHPCS to latest stable release. However there is a possible bug when I run a code check on my php file using the Squiz standard.
I will file a bug when I create a login on PEAR, meanwhile if you can check with this -
c:\> phpcs --report=checkstyle --standard=Squiz wp-login.php > report.xml
Here the wp-login.php file is the one which comes under wordpress root directory (http://wordpress.org/download/)
ERROR -
Notice: Undefined index: scope_closer in C:\wamp\bin\php\php5.2.5\PEAR\PHP\CodeSniffer\Standards\Squiz\Sniffs\Commenting\LongConditionClosingCommentSniff.php on line 115
Notice: Undefined index: in C:\wamp\bin\php\php5.2.5\PEAR\PHP\CodeSniffer\Standards\Squiz\Sniffs\Commenting\LongConditionClosingCommentSniff.php on line 116
Keep up the good work! :)
Hi, report bugs through the PEAR bug tracker and I will take a look into them:
http://pear.php.net/bugs/report.php?package=PHP_CodeSniffer
This report has a lot of good information in it so it should be fairly easy to track down. This sort of error is normally caused by a specific style of coding that phpcs can't parse correctly, or an assumption made by one of the Squiz standards about the coding style used.
Hi Greg,
First off PHP_CodeSniffer rocks. Kudos on that.
I have two queries if you can let me know kindly.
1. Usually code is indented with TABS but phpcs reports says otherwise. (ie. Use spaces instead of tabs) Even if this is the case, how can we toggle this option?
2. Like eclipse plugin checkstyle, do we have (or are u planning) a consolidated html report which user can click on a file name (link) to see all its errors/warnings?
Chris
I want to know the same thing about how to ignore a pattern (for example the one who doesn't allow tabs).
I put in the terminal: phpcs --ignore=formatting but nothing happened :(
Thanks for your help
@Anonymous + Carolina
When you use an existing standard from PHPCS, you need to generally follow its rules. So to have a standard that enforces tabs instead of spaces you would need to write your own coding standard (there are end user docs over at PEAR about how to do this).
However, PHPCS does have a command line argument that allows you to tell it to convert tabs to spaces before the file is checked, stopping tabs from creating errors. You need to tell PHPCS how many spaces each tab represents (normally 4). See the "Replacing Tabs with Spaces" section of the Advanced Usage docs for more info:
http://pear.php.net/manual/en/package.php.php-codesniffer.advanced-usage.php
@Anonymous
I have thought about a HTML interface before but I have just never got around to it, probably because I wouldn't use it myself as I don't currently have a need for it.
Christian did see a need for it and used the XML output and a custom script to generate HTML output himself. You can read about it here:
http://gregsherwood.blogspot.com/2007/10/all-pear-packages-now-checked-with.html
Post a Comment