Depending on the audience, I may describe myself as one of the following: engineer, developer, programmer or coder. Anyone who wears the above hats will wrangle with instructions that a computer somewhere will know what to do with. These instructions, represented in programming code, may be performed by multiple machines and an incomprehensive amount of times. So when do coding standards come into play?
The author will not hold the only pair of eyeballs that will ever see the code. Programming is often a collaborative effort and, just like literature, no two authors are the same. Programmers must agree on the standard which describes the style and formatting of the code. This problem has been inherited from the language designers, which allows the same task to be accomplished in multiple ways.
Leaning on static analysis of source code is an efficient and direct way of triaging coding standard breaches. Relying on a tool removes the need to review code in its entirety for formatting issues. Static analysis will also bring to light the parts of the specification which the user may not be familiar with. I depend daily on PHP CodeSniffer to scrutinise my code prior to contributing to it.
PHP_CodeSniffer is available via PEAR and can be installed via the command line:
pear install PHP_CodeSniffer
Once installed, the executable phpcs will act as judge, jury and executioner for coding standard violations. Thus, the relentless internal coding standard debate dissipates and a new central authority to verify coding standards is established.
Testing a single file is simple:
phpcs example.php
By default the PEAR standard is configured, though other standards such as Zend, MySource, PHPCS and Squiz are available. Testing Zend for example is quick:
phpcs --standard=Zend example.php
I cover PHP_CodeSniffer and static analysis tools PHP Mess Detector and JSHint in my Static Analysis of PHP and JavaScript presentation, with a video also available.
Trackbacks/Pingbacks