Tuesday, March 11. 2008
A useful idea for helping to enforce PHP code standards
extending PHP_CodeSniffer by Raphael Stolt shows how to quite easily add to a tool that will report what parts of your PHP source needs a clean-up, from the built in ‘sniffs’ for coding standards, and now adding to that for some slightly more opinionated choices on the maximum number of lines per function, or functions per class.
This could be a start of a whole collection of additional classes for additional checks.
The only challenge I see at the moment (and I don’t think it’s a big one, though I’ve not tried it, so it might not even exist, I’ve just not had the opportunity to look yet) is having to put code into the PEAR directory path, since that is where PHP_CodeSniffer is looking for the base library. I do see that they use long PEAR class-names, so it may just a matter of having the phpcs tool look elsewhere for the base coding style class.
1234.20080102 dev’). After a quick wander around the newly checked out version, maybe run a set of unit tests, just for security, it’s just as easy to put a similar ‘live’ symlink into place with a new link.
If there is ever a problem, rolling back to a previous live version is just as easy. Other configuration changes are made within the code on the apache servername, or the machine’s own hostname (more useful for CLI scripts, generally run from cron).
There are some downsides – with a complete checkout of a 40-some megabyte website (it’s mostly the Zend Framework and other libraries from which I use a number of files, though rarely all), it takes a little while (not too long, it’s a gigabit link between the repository and the main webserver) and there are also some potential caching issues (Etags are usually based on the file inodes), but as we plan to move to a multi-machine cluster – and the images aren’t being served from Apache, but a dedicated image webserver, that’s not a significant issue – and even on Apache we don’t have Etags enabled (Yslow from Yahoo also suggests that).
[edit: 18:06]
Ahah, some investigation – and copious use of echos in the phpcs script, and /usr/share/php/PHP/CodeSniffer.php class:
Creating your own standards, and using them from anywhere on the filesystem – not having to link from inside the PEAR/PHP/CodeSniffer directory:
The coding standard class with your extension:
The class is called PHP_CodeSniffer_Standards_Example_ExampleCodingStandard – the two ‘Example’s being the name of the coding standard. The file is called ‘Example/ExampleCodingStandard.php’
<?php
// in the …./Example/ directory
require_once ‘PHP/CodeSniffer/Standards/CodingStandard.php’;
class PHP_CodeSniffer_Standards_Example_ExampleCodingStandard extends PHP_CodeSniffer_Standards_CodingStandard
{
function getIncludedSniffs()
{
return array(
‘PEAR’, // the main PEAR standards
// Add our other standards, all from a subdir
dirname(FILE).‘/Standards’,
);
}
function getExcludedSniffs()
{
return array();
}
}
And in the subdir: .../Example/Standards/
– Raphael’s ToManyMethodsSniff.php and MethodLengthSniff.php files “from his post”:http://raphaelstolt.blogspot.com/2008/03/sniffing-refactoring-needs.html
To call it:
# we have to give the full path to the file called Example/ExampleCodingStandard.php
# $(pwd)/ is just Bash-ish for outputting the current directory name
phpcs —standard=$(pwd)/Example /path/to/file/to/check/ | less
