All PHP code is to be enclosed by full PHP tags:<?php and ?>. Short tags (<? and ?>) or ASP-style tags (<% and %>) are not allowed.

Tabs are to be replaced by four space characters. Most IDEs and text editors can be set to do this automatically.

The suggested maximum number of characters per line is 80 characters, although just about all GUI-based editing tools can easily accommodate more characters. This convention takes into consideration that command line interfaces are often limited to 80 characters. The absolute maximum number of characters per line is 120. Lines of code with more characters are not acceptable.

Lines must end only with a standard Unix linefeed (LF). Linefeeds are represented as ordinal 10, or hexadecimal 0x0A.

Carriage returns (CR) (0x0D), commonly used on Macintosh computers, and carriage return/linefeed combinations (CRLF) (0x0D, 0x0A), commonly used on Windows computers, are not allowed.

For readability, spaces are required at the following code sections:

Put only one statement per line. Multiple statements on a single line are expressly forbidden because they are easily overlooked when reading the code. Spreading a single statement over multiple lines is discouraged unless it clearly improves readability of the code.

<?php
// unnecessary and confusing
echo ($errorCondition === true)
?
"too bad\n"
:
"nice\n";
// keep ';' on the same line as the statement
// don't do this:
echo "goodbye!\n"
;
// must not put multiple statements on a line
echo 'An error has occurred'; exit;
?>

Use only double quotes to define strings if you are taking advantage of variable interpolation or the string contains formatting characters or single quotes, such as', \n or \t. In all other instances, single quotes should be used as they result in less work for the parser and faster execution of your script.

Strings exceeding the maximum line length should be broken into smaller segments and concatenated using the dot notation.

Long strings should use the heredoc notation if possible.

<?php
// defining a simple string
$myOutput = 'This is an awesome book!';
$adjectives = array('nicer',
'better',
'cleaner');
// string with variable interpolation and formatting characters
echo "Reading this book makes a good PHP programer $adjectives[1].\n";
// double quotes containing single quote
echo "This book's content will make you a better developer!";
// defining long strings by breaking them up
$chapterDesc = 'In this chapter, we are tyring to explore how'
'a thorough and clear common coding standard'
'benefits the project as well as each individual'
'developer.';
// I'm not much of a poet, but this is how you use the heredoc syntax
$poem = <<<ENDOFSTRING
Roses are red,
violets are blue,
this is my poem
for the code in you.
ENDOFSTRING;
?>

Numerically indexed arrays should have base index 0 whenever possible. For numerically indexed array, multiple values per line are allowed, but spaces must be inserted to align the first item of each line.

Associative arrays should be declared such that key-value pairs should be listed one to each line. White space must be inserted so as to align the names, assignment operators, and values of all items. Single quotes are always to be used if the key value is a string.

<?php
// simple numerically indexed array
$myFruits = array('apples', 'bananas', 'cherries');

// use bracket syntax within string to access array
echo "My favorite fruits are {$myFruits[2]}.\n\n";
// longer numerically indexed array
$myLongList = array('The', 'quick', 'brown' ,'fox',
'jumped', 'over', 'the', 'lazy',
'fox', '.');

// use bracket syntax with variable as index to access array
$listSize = count($myLongList);
for ($i = 0; $i < $listSize; $i++) {
echo $myLongList[$i];
echo ($i < $listSize - 2) ? ' ' : '';
}
echo "\n\n";
// associative array; everything lines up
$spanAdj = array('green' => 'verde',
'little' => 'poquito',
'big' => 'grande');

// using a foreach construct to access both keys and values
foreach ($spanAdj as $english => $spanish) {
echo "'" . $spanish . "' means '" . $english . "' in Spanish.\n";
}
?>

The above code fragment outputs the following text when executed:

Conditional tests should be written on one line if possible. For long and complex conditional tests, line breaks should be inserted before each combining operator with the line indented for combining operators to line up. The starting curly brace should appear on the same line as the last conditional test. Control statements should have one space between the control keyword and the opening parenthesis, so as to distinguish them from function calls.

<?php
// all conditionals on the same line
if ($myValue <= -1 || $myValue > 100) {

doSomethingImportant();
}
// too many conditional for one line
// break up conditionals like this ...
if ($myValue > 5
|| $myValue < 5
|| $myValue == 0
|| $myValue == -3) {

doSomethingElseImportant();
}
?>

<?php
if (is_array($myHash)) {
throw new Exception("myHash must be an array!");
} elseif (array_key_exists('index', $myHash)) {
echo "The key 'index' exists.\n";
} else {
echo "The key 'index' does NOT exists.\n";
}
?>

<?php
switch ($temperature) {
case 50:
echo "Let's stay home and write some code.\n";
break;
case 80:
echo "Let's go to the beach\n";
break;
default:
echo "Go to jail. Do not pass go.\n";
break;
}
?>

Both class and method definitions follow the "one true brace" convention. That is to say, the opening and closing curly brackets are to appear on a line by themselves:

<?php
// showing "one true brace" convention
class Otb
{
// for metods as well
public method doSomething()
{
// your clever and immensely important code goes here
...
}
}
?>

Classes should be named after the objects they represent. Try to stay away from descriptive phrases (too long), incorporating parent class or interface names, or using verbs.

Examples of bad class names are:

Examples of good names are as follows:

Class names should reflect the path relative to the root class directory. Directories are to be delimited by the underscore character ("_"). The first letter of each word/directory name is to be capitalized. No other characters are to be capitalized. In particular, abbreviations should adhere to this convention as well. Furthermore, only alphanumeric characters and the underscore character are allowed. Use of numbers is discouraged.

The following PHP segment takes a class file path and converts it to the corresponding class name:

<?php
class ClassNameConverter
{
public static $classRootDir = array('var', 'www', 'sites', 'my_app', 'includes', 'classes');
public static function makeClassName($absolutePath)
{
$platformClassRootDir = DIRECTORY_SEPARATOR .
implode(DIRECTORY_SEPARATOR, self::$classRootDir) .
DIRECTORY_SEPARATOR;
// remove path leading to class root directory
$absolutePath = str_replace($platformClassRootDir, '', $absolutePath);
// replace directory separators with underscores
// and capitalize each word/directory
$parts = explode(DIRECTORY_SEPARATOR, $absolutePath);
foreach ($parts as $index => $value) {
$parts[$index] = ucfirst(strtolower($value));
}
// join with underscores
$absolutePath = implode('_', $parts);
// remove trailing file extension
$absolutePath = str_replace('.php', '', $absolutePath);
return $absolutePath;
}
}
$classNameExamples =
array('/var/www/sites/my_app/includes/classes/logging/db/Mysql.php',
'/var/www/sites/my_app/includes/classes/logging/db/MysqlPatched.php',
'/var/www/sites/my_app/includes/classes/caching_lib/Memcached.php'
);
foreach ($classNameExamples as $path) {
echo $path . ' converts to ' .
ClassNameConverter::makeClassName($path) . "\n";
}
?>

Here is the corresponding output:

Properties and variables should start with a lower case letter, contain only alphanumeric characters, and generally follow the "camelCase" convention. Every effort should be made to make property names as descriptive as possible without their length getting excessive. Underscore characters are not allowed in property and variable names.

Short variable names, such as $i or $cnt are only allowed in very short looping constructs.

Names of constants should only contain alphanumeric characters. Words are to be separated by the underscore character. Names should be as descriptive as possible, but more than three words are discouraged.

Similar to property names, method and function names should contain only alphanumeric characters and follow the "camel case" convention. They should start with a lower case letter and contain no underscore characters. Class methods must always be preceded by one of the three visibility specifiers: public, protected, or private.

Method names should be descriptive as to their purpose. However, excessive length is discouraged.

Accessor methods for object properties should always be named set<PropertyName> and get<PropertyName>.

The following listing illustrates proper names for properties, methods, classes, and constants:

<?php
class MessageQueue
{
// upper case constant with underscores
const MAX_MESSAGES = 100;
// descriptive properties using camelCase
private $messageQueue = array("one\ntwo");
private $currentMessageIndex = -1;
// setter method for $currentMessageIndex
public setCurrentMessageIndex($currentMessageIndex)
{
$this->currentMessageIndex = (int)$currentMessageIndex;
}
// getter method for $currentMessageIndex
public getCurrentMessageIndex()
{
return $this->currentMessageIndex;
}
// is<Attribute> method returns boolean
public function isQueueFull()
{
return count($this->messageQueue) == self::MAX_MESSAGES;
}
// has<Attribute> method returns boolean
public function hasMessages()
{
return (is_array($this->messageQueue) && count($this->messageQueue) > 0);
}
// descriptive take action method
public function resetQueue()
{
$this->messageQueue = null;
}
// descriptive take action method
public function convertMessagesToHtml()
{
// local copy of message queue
$myMessages = $this->messageQueue;
// $i is acceptable in a short for-loop
for ($i = 0; $i < sizeof($myMessages); $i++) {
$myMessages[$i] = nl2br($myMessages[$i]);
}
return $myMessages;
}
// additional methods to manage message queue ...
}
?>

Whenever possible, functions should type-hint by specifying the class of the parameter. Furthermore, as of PHP 5.1, arrays can be type-hinted. Therefore, arrays should always be type hinted — especially when passing a hashed array instead of individual parameters.

<?php
class SomeClass
{
// method requires an object of type MyClass
public function doSomething(MyClass $myClass)

{
echo 'If we made it this far, we know that the name ' .
'of the class in the parameter: ' . get_class($myClass);
}
// method requires an array
public function passMeAnArray(array $myArray)

{
// we don't need to test is_array($myArr)
echo "The parameter array contains the following items:\n";
print_r($myArr);
}
}
?>

If something goes wrong during object creation, the calling code may be left in a state of uncertainty. For example, throwing an exception in the constructor will prevent the object from being instantiated. Therefore, it is advisable to separate construction and initialization of the object. A short constructor will be responsible for instantiating the object, after which, an init function is responsible for handling object initialization.

<?php
class MyClass
{
private myAttrib;
// short constructor - no parameters this time
public function __construct()
{
// intentionally left blank
}
// initialization method to be called
// immediately after object instantiation
public function init($var)

{
$this->myAttrib = trim$(var);
}
}
// first we instantiate the object
$myObject = new MyClass();
// then we initialize the object
$myObject->init('a string literal');
?>

Each class definition should be in a separate source file. And, there should be no additional code (outside the class) in that file. The name of the file should reflect the name of the class. For example, class Message should be defined in the file Message.php.

The directory hierarchy in which the class files are organized should be reflected in the name of the class. For example, assume that we decided to put our classes directory inside an includes directory:

includes/
classes/
Parser/
FileParser/
CommonLog.php

The file CommonLog.php should contain a class called Parser_FileParser_CommonLog. This convention will make it easier to comprehend a class's position in the class hierarchy. It also makes it easier for the autoload() function to locate classes.

All properties and methods of a class must have one of three visibility specifiers: public, protected, or private. Direct access to properties is discouraged in favor of corresponding getter and setter methods: get/set<Attribute>() — even when accessing properties from within a class. Magic methods may be used to provide access to the properties.

<?php
class AlwaysUseGetters
{
// private property not accessible outside this class
private $myValue;
// setter method
public function setMyValue($myValue)
{
$this->myValue = $myValue;
}
// getter method
public function getMyValue()
{
return $this->myValue;
}
public function doSomething($text)
{
// use getter to retrieve property
return $text . $this->getMyValue() . '!';
}
}
// instantiate object
$myAwc = new AlwaysUseGetters();
// use setter to set property
$myAwc->setMyValue('book');
// call method to illustrate use of getter
echo $myAwc->doSomething('This is an awesome ');
?>

Use require_once to unconditionally include a PHP file. Analogously, use include_once to conditionally include a PHP file, for example in a factory method. Since require_once and include_once share the same internal file list, a file will never be included more than once even if you're mixing the two constructs.

Never use require or include as they provide the same functionality as require_once and include_once, but leave open the possibility of unintentionally including the same PHP file multiple times.

<?php
// use of require_once
require_once('logging/Database/DbLogger.php');
class DbConnector
{
// these are the RDBMs we support
public static $supportedDbVendords = array('mysql',
'oracle',
'mssql');
// factory method using include_once
public static function makeDbConnection($dbVendor = 'mysql')
{
if (in_array($dbVendor, self::$supportedDbVendords)) {
// construct the class name from the DB vendor name
$className = ucfirst($dbVendor);
include_once 'database/drivers/' .
$className . '.php';
return new $className();
} else {
// unsupported RDBMs -> throw exception
throw new Exception('Unsupported RDBSs: ' . $dbVendor);
}
}
}
// use factory method to get DB connection
$dbHandle = MakeAnObject::makeDbConnection();
?>

Developers are encouraged to provide inline comments to clarify logic. Double forward slashes (//) are used to indicate comments. C or Perl-style hash marks (#) to signal comments are not allowed. For readability, all inline comments are to be preceded by a blank line. Here is the previous listing with inline comments. Notice how blank lines were added to make it more readable.

<?php
// inline comment preceding if statement
if (is_array($myHash)) {
// inline comment indented with code
throw new Exception("myHash must be an array!");
// inline comment preceding elseif (preceded by blank line)
} elseif (array_key_exists('index', $myHash)) {
echo "The key 'index' exists.\n";
// inline comment preceding else (preceded by blank line)
} else {
echo "The key 'index' does NOT exists.\n";
}
?>

The phpDocumentor type documentation blocks are required in four places:

Following is a table of required and recommended phpDocumentor tags. Please refer to the chapter on documentation for more details.

where

Χ = required

[Χ] = recommended where applicable

blank = do not use

Let's start by installing PHP_CodeSniffer directly from the PEAR site using their handy command line installer. When I built and installed PHP on my system, I had it put everything in a sub-folder of my local Apache installation. In my case, the PHP root folder is therefore in /usr/local/apache2/php/. This is where you can find the PEAR executable among other handy PHP utilities. The most recent version at the time of this writing is 1.2.1.

Installing the package is simply a matter of telling the pear executable to download and install it. You should see something similar to the following lines cascading down your screen.

Afterwards, listing the contents of your PHP installations bin directory should show the phpcs executable in addition to everything else you had in that directory.

Using PHP_CodeSniffer to validate one or more files against a coding standard is pretty straightforward. You simply invoke the phpcs executable and pass the file or directory to check as an argument.

Here is some sample output from checking one of the listings for this chapter:

As you can see from the output, checking against the default coding standard (Zend), phpcs has found three errors and one warning. For each of the problems it finds, phpcs reports the line number of the source file, the severity of the issue (error, warning, and so on) and a description. The three errors it found aren't really part of the coding standard that we defined earlier in this chapter. However, the warning indicates that the maximum line number, which we defined in our own standard to be 80 characters, was exceeded. We could have suppressed the warnings by adding the-n switch to the command line. At this point, we should fix the issue and re-run phpcs to confirm that there are no additional issues detected.

Rather than duplicating the PHP_CodeSniffer documentation here, I want to use this section to briefly list the available runtime options and highlight some of the more useful ones.

There are various command line options that let you customize what to check, how to check, and how to format the ouput. Type phpcs --help to see all of the arguments understood by the script.

PHP_CodeSniffer comes with several predefined coding standards. Typing phpcs i will tell which coding standards are installed. The version of the tool I installed came with the following standards: MySource, PEAR, PHPCS, Squiz, and Zend. To tell phpcs to check against a specific standard, simply add the following option to the command line: --standard=Zend.

The last useful command line switch I would like to point out is the --report=summary argument. When recursively checking a directory of source files, the output can get rather long. This switch prints a summary report with one line per file rather than outputting each individual issue it identified. Here is the summary report for all code listings in this chapter up to this point.

Here is a list of additional features you can customize from the command line. Please refer to the PHP_CodeSniffer online documentation for details.

Being able to check code against an existing and established coding standard, such as Zend, is useful, but the real power of PHP_CodeSniffer lies in its extensibility. By defining our own coding standard in a format PHP_CodeSniffer understands, we can use it to check conformance to our own standard.

Defining your own coding standard involves a three-step process. The steps are as follows:

Creating the directories

The directory structure for each coding standard definition is simple. From the command line, the following set of commands can be used to create the initial set of directories and files of a hypothetical coding PHP_CodeSniffer standard definition.

We start by creating a directory to hold all the files associated with our coding standard definition, ProjectStandard. In that directory, we create a class file called ProjectStandardCodingStandard.php that identifies our directory as one containing a PHP_CodeSniffer coding standard definition. This class is also responsible for communicating with the main phpcs executable regarding some of the details of our coding standard (more about that later).

Next we create a directory called Sniff, which will contain descriptions of individual coding standard rules, or collections (directories thereof). In our case, we plan on creating rules regarding naming conventions and line length, which is why we are creating directories NamingConventions and LineLength inside the Sniffs directory. Each of these sub-directories then contains one or more individual sniff files: LimitLineLengthSniff.php, ClassNamesSniff.php, VariableNamesSniff.php, and PropertyNamesSniff.php.

<?php
// make sure the parent class is in our include path
if (class_exists('PHP_CodeSniffer_Standards_CodingStandard', true) === false) {
throw new PHP_CodeSniffer_Exception('Class PHP_CodeSniffer_Standards_CodingStandard not found');
}
// our main coding standard class definition
class PHP_CodeSniffer_Standards_ProjectStandard_ProjectStandardCodingStandard extends PHP_CodeSniffer_Standards_CodingStandard
{
// include sniffs from other directories or even whole coding standards
// great way to create your standard and build on it
public function getIncludedSniffs()
{
// return an array of sniffs, directories of sniffs,
// or coding standards to include
return array(
'Generic'
);
}
// exclude sniffs from previously included ones
public function getExcludedSniffs()
{
// return a list of sniffs or directories of sniffs to exclude
return array(
'Generic/Sniffs/LineLengthSniff.php'
);
}
}
?>

Creating Sniffs

Each of the rules we formulated to express our coding standard earlier in the chapter, can be described using a sniff class file that PHP_CodeSniffer can use. However, before we jump in and really get our hands dirty, it is a good idea to review how tokenization works. After all, PHP_CodeSniffer builds on and expands PHP's inbuilt tokenizer extension.

Note

Tokenization is the process of breaking input text into meaningful parts. When combined with a classification and/or description, each such part is considered a token.

Tokenization

PHP uses the Zend Engine's tokenizer at its core to parse and interpret PHP source files. Lucky for us, the tokenizer is also directly accessible via two functions in the language's top-level namespace: token_get_all() and token_get_name().

Tokenization consists of taking input text and breaking it up into meaningful segments. Each segment can optionally carry a label, explanation, or additional detail. Let's look at an example of PHP code being tokenized by the Zend Engine.

<?php
// get the contents of this file into a variable
$thisFile = file_get_contents(__FILE__);
// get the token stack
$tokenStack = token_get_all($thisFile);
$currentLine = 0;
// output each token & look up the corresponding name
foreach ($tokenStack as $token) {
// most tokens are arrays
if (is_array($token)) {
if ($currentLine < $token[2]) {
$currentLine++;
echo "Line $currentLine:\n";
}
echo "\t" . token_name($token[0]) . ': ' . rtrim($token[1]) . "\n";
// some tokens are just strings
} else {
echo "\tString: " . rtrim($token) . "\n";
}
}
?>

The above code snippet runs itself through the tokenizer, which results in the following output:

We formatted our output a littler nicer, but the first token essentially looks like this:

Array(
[0] => 367
[1] => <?php
[2] => 1
)

In this case, 367 is the value of the parser token, which corresponds to T_OPEN_TAG when we look it up with the token_name() function.<?php is the actual text of the token and 1 is the line number on which the token occurs. You can look up the complete list of tokenizer token constants in the online PHP manual, or the following code snippet will list the ones that are defined for your version of PHP.

<?php
// get all constants organized by category
$allTokens = get_defined_constants(true);
// we're only interested in tokenizer constants
print_r($allTokens["tokenizer"]);
?>

As you can see for yourself, tokens contain a lot of information that is useful to programmatically understand what an analyzed portion of code is doing. PHP_CodeSniffer builds upon the existing tokenization extension and built-in tokens by providing additional tokens to provide even finer granularity when examining PHP code.

Writing our first sniff

Now that you know what tokens are, it will be much easier to understand what the individual sniffs are doing. First of all, a sniff registers with the main executable the tokens in which it is interested using the register() method. That way, the main code can hand over execution to the sniff's process() method whenever it encounters such a token. For example, a sniff trying to validate that a code file has the proper PHP opening and/or closing tag might register interest in the T_OPEN_TAG with the parent code. That is exactly what we're doing in the following listing:

<?php
// sniff class definition must implement the
// PHP_CodeSniffer_Sniff interface
class ProjectStandard_Sniffs_Syntax_FullPhpTagsSniff implements PHP_CodeSniffer_Sniff
{
// register for the tokens we're interested in
public function register()
{
return array(T_OPEN_TAG);
}
// process each occurrence of the token in this method
public function process(PHP_CodeSniffer_File $phpcsFile, $stackPtr)
{
$tokens = $phpcsFile->getTokens();
// warn if the opening PHP tag is not the first token in the file
if ($stackPtr != 0) {
$phpcsFile->addWarning('Nothing should precede the PHP open tag.', $stackPtr);
}
// error if full PHP open tag is not used
if ($tokens[$stackPtr]['content'] != '<?php') {
$phpcsFile->addError('Only full PHP opening tags are allowed.', $stackPtr);
}
// all files must have closing tag
if ($token[sizeof($tokens) - 1]['type'] != T_CLOSE_TAG) {
$phpcsFile->addError('All files must end with a closing PHP tag.', $stackPtr);
}
}
sniffssniffswriting}
?>

Let's take a closer look at the process() method, which takes two parameters. The first one is a reference to a PHP_CodeSniffer_File object, which we can use to access the token stack. The second argument is an array index to the current token in the stack.

Armed with that information, we can start validating the code via the token stack. First, we use the PHP_CodeSniffer_File's addWarning() method to display a warning message whenever the very first token is not the PHP open tag. Next, we use the addError() method to display an error message to the user whenever the opening tag doesn't match the string "<?php" since that is the only opening tag that our coding standard allows. Lastly, we display an error message if the last token in the stack is anything other than the closing PHP tag.

That's it. The main phpcs executable does the rest. It tokenizes the input file(s), calls all registered sniffs for each occurrence of their respective token, and displays nicely formatted output to the user.

You may have noticed in the above listing that we used the values of the token's 'content' and 'type' attributes. If you recall, the tokens returned by the standard PHP tokenizer did not have those attributes. Instead, PHP_CodeSniffer adds those and other attributes. Following is a list of token attributes that are always available. Depending on the type of token, additional attributes might be available. You should consult the PHP_CodeSniffer API documentation for details.

Attribute name	Example	Description
code	301	The token type code (see token_get_all())
content	if	The token content
type	T_IF	The token name
line	56	The line number when the token is located
column	12	The column in the line where this token starts (starts from 1)
level	2	The depth a token is within the scopes open
Conditions	Array( 2 => 50, 9 => 353 )	A list of scope condition token positions => codes that opened the scopes that this token exists in (see conditional tokens)

Extending existing sniffs

We have already seen that we can include sniffs from other coding standards in our own. However, we can take it a step further and make an existing sniff do all the work while still implementing our own standard. For example, the "Generic" coding standard includes a sniff to check for maximum line length. As it happens, the suggested maximum line length is 80 characters — the same as in our own standard. However, the absolute maximum line length is 100; whereas, our standard allows for up to 120 characters per line. Therefore, all we have to do is extend the existing sniff and overwrite the protected property $absoluteLineLimit as in the following listing.

<?php
if (class_exists('Generic_Sniffs_Files_LineLengthSniff', true) === false) {
throw new PHP_CodeSniffer_Exception('Class Generic_Sniffs_Files_LineLengthSniff not found');
}
// class to check line length in number of characters
// note: we're overwriting an existing sniff from the generic coding standard
class Zend_Sniffs_Files_LineLengthSniff extends Generic_Sniffs_Files_LineLengthSniff
{
// we generate an error when exceeding the absolute
// maximum line length
protected $absoluteLineLimit = 120;

}
?>

Automated code checks

Even though PHP_CodeSniffer is available, there is no guarantee that individual developers will actually take advantage of it. However, in a team environment, the lead developer can take several steps to make sure the team members adhere to the chosen common standard. First, the code base should be scheduled for an automated check once a day during active development. A simple (insert you favorite scheduler utility here) job can process all the source files and send an email to everybody in the team.

However, it is possible to take things a step further. Assuming that you are using a source code control system, most of these systems provide hooks at various stages of checking out or committing source code. The most commonly used hook is the pre-commit hook. In other words, the source code control system executes any number of user-configurable steps before committing the code. The outcome of these steps impact whether the use is allowed to commit the code or not. In the case of our coding standard, we can configure the pre-commit hook to run any PHP source files being committed through PHP_CodeSniffer and only proceed if no errors and/or warnings are being generated. In essence, this is a way that your team only accepts contributions from individual developers if they adhere to the team's coding standard.

For a detailed example of how to configure the Subversion source code control system with a PHP_CodeSniffer pre-commit hook, please consult the chapter on source code and version control.