Creating coding standards for PHP_CodeSniffer

When our project is supervised by a continous integration platform, we are (hopefully) using static code analysis tools. One of the best for analysing PHP code
is PHP_CodeSniffer which integrates fine into systems like PhpUnderControl, Hudson or Bamboo. But in some cases the pre-installed coding standards like PEAR or Zend might not be sufficient for our
current project or we want to deviate. This is the moment when we want to be able to create a custom one that fits our special needs. In this article I want to share my first experiences
with you about how to create a custom coding standard for PHP_CodeSniffer.

What’s a standard in PHP_CodeSniffer?

A coding standard is nothing more than a set of rules. Each rule – called „sniff“ – is a class,
that checks the code for a particular requirement. There could be one that verifies that no tabs are used but spaces instead.
Another sniff could check if variable names stand in correct camel case, whereas a third one could check if there is only one class in each file.
When we locate the installation path of CodeSniffer and browse to the subfolder Standards
we will find this structure:

A standard (here PEAR) is a subfolder located in the Standards folder.
It needs a base class named after the standard followed by CodingStandard.php. Sniffs go into the subfolder Sniffs.
Grouping Sniffs into subfolders is best practise but not necessary. CodeSniffer grabs all
sniffs from all subfolders anyway.

When running PHP_CodeSniffer the standard’s name is referenced like this:

Of course phpcs comes with some pre-installed standards.
The Option -i tells us which ones are installed right now and therefor tells us, which standards could be used to analyse our code:

Setting up the file structure for a custom standard

Now we are ready to create a structure for our custom standard. We could create a structure like this:

The file MyStandardCodingStandard.php contains:

What’s happening there?
First we make sure that the class PHP_CodeSniffer_Standards_CodingStandard exists because we want to extend it. Afterwards we define our custom coding standard class. The method getIncludeSniffs()
defines which sniffs should be used in this standard. This is a possibility to reuse sniffs of external standards.
That’s great because we don’t want to reinvent the wheel again and again. If other standards already have a sniff we’d like to use in our
standard, we can inject it by just adding it to this array.
PHP_CodeSniffer scans the Sniffs folder for our own sniffs automatically. If you add them nonetheless, they will be executed twice.

That’s it! Our standard is ready.
Ok, it doesn’t do much more than executing the included external sniffs, but it’s already working. That means: if we want to create our own collection of sniffs taken from the Generic, PEAR,
Squiz or Zend standard we are fine by just gluing them together to our custom standard. I want to encourage you to delve deeper into the already coded sniffs. A lot of sniffs – and I really mean „a
lot“ – are already done.

Coding a sniff

Before we can start to build our sniff we have to understand how CodeSniffer works and how things are processed. At first it splits the file to be analysed into tokens. Our sniff needs to register the types of tokens for which it wants to be
invoked. The list of available token types can be found in Tokens.php and looks like

PHP_CodeSniffer is doing all the dirty work for us. It splits up the file into tokens, categorizes them and calls our sniff automatically, if we registered it for that kind of token.
Now that we know what tokens we can deal with, we are ready to code our first sniff.

Coding the first Sniff

For demonstration purposes our first sniff will be a very basic but working one.
We simply want to make sure that each class name starts with a capital letter – that’s our requirement.
First we create a file we want phpcs to check and call it checkMe.php.
Of course we write the class name in lower case to check if our sniff detects this correctly:

Now we build our sniff, name it ValidClassNameSniff.php and save it in our MyStandard/Sniffs

The register() method is used to tell CodeSniffer in which tokens we are interested.
Each time a token of the added type is detected CodeSniffer invokes our process()
method and hands over a PHP_Code_Sniffer_File instance and an integer pointing to the offset
of the deteced token. With

we get the complete list of all tokens of this file. Let us add a quick and dirty

to get an idea what we are dealing with. The output gives us important information:

The pointer points to index 1 which has a subindex type which is the token type we registered for.
But that’s not the class name we are looking for!
We have to move the pointer to the token containing the class name and grab it from the index content.

Of course we could increase the pointer by 2 because there is one whitespace between
the invoking token and the class name. This would work for this file.
But what if there are more whitespaces or if the class would look like this?

Our static strategy to simply add 2 to the invoking token index would fail.

Luckily the class PHP_Code_Sniffer_File offers the method
findNext($tokenType, $stackPtr) to find the next token of the given type.
As we can see in our debug output our class name is a token of the type T_STRING.
So we can use the method to look for the next T_STRING and therefor are able to skip all
whitespaces and comments easily.

Btw: when coding sniffs it is a good idea to take a look at the methods CodeSniffer
already offers. Read the DocBlocks that contain many hints.
After we have found the class name it is easy to analyse it. Here we use a preg_match
pattern for uppercase letters and fire the addError() method to let CodeSniffer
do its complaining.
When we write other sniffs and want to distinguish between errors and warnings
there is also a method addWarning().
Let’s take a look at the generated output:

CodeSniffer automatically adds the line number, the kind of error and our output text. Our sniff is ready.
Of course CodeSniffer can not only check a single file but directories with subfolders.

Now you should be able to write your own sniffs. At least I hope you get the idea.
Sometimes it can get a little tricky to get the tokens you are interested in,
but I’m sure you will find a way.

Feel free to add notes to this article and use the comment function.
Depending on the public interest I am willing to do a follow up with a use case
of our project in progress. At least I hope I could catch your interest in building a custom coding standard. It’s only magic until you tried to do it yourself. ;)

Best regards,
Daniel Schlichtholz

Für neue Blogupdates anmelden:

9 Gedanken zu “Creating coding standards for PHP_CodeSniffer

  1. Hi Daniel,

    What I really enjoy in the latest version of phpcs (1.3.*) is that you can specify your own ruleset xml to alter an existing standard. For example, if you like the pear sniffs but want your linelength to be a bit longer than 80 characters:

    [?xml version=“1.0″?]
    [ruleset name=“My PEAR“]

    [rule ref=“PEAR“/]

    [rule ref=“Generic.Files.LineLength“]
    [property name=“lineLimit“ value=“120″/]


    you can call phpcs like this:

    phpcs –standard=/path/to/custom_ruleset.xml /path/to/code

  2. Suppose i want to create a rule to find a particular string say „hello_world“ in the source code ,which token i have to register and how to find the „hello_world“ through out my source code

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *