WordPress CodeSniffer Standard

CodeSniffer is a PEAR package that checks PHP code for violations of coding standards. According to the developers:

It is an essential development tool that ensures your code remains clean and consistent. It can also help prevent some common semantic errors made by developers.

While it won’t make you bug-free, it is another tool to help you produce better quality code, and is very useful when working with a team of developers. CodeSniffer thoughtfully comes with several standards to verify code against the PEAR, Zend, and Squiz coding standards. What follows is a CodeSniffer standard that adheres to the WordPress Coding Standard. Hurray for coding violations!

The WordPress Coding Standard will check for:

  • Brace usage
  • Spaces around logic statements, assignments, functions, and classes
  • No CamelCase function names
  • Deprecated WordPress functions usage, with suggested alternatives
  • Use of posix regular expressions
  • Filenames with an underscore

Installation

Details about how to install CodeSniffer can be found at the CodeSniffer site. The WordPress Coding Standard can be installed by following these steps:

  1. pear install http://urbangiraffe.com/resources/
    download/plugin/PHP_CodeSniffer_Standards_WordPress-0.0.1.tgz

NOTE: The above line has been split to fit the page – you should enter it as one line.

Alternatively if you do not have access to the pear command you can install it manually:

  1. Download PHP_CodeSniffer_Standards_WordPress-0.0.1.tgz
  2. Unpack
  3. Copy PHP_CodeSniffer_Standards_WordPress-0.0.1/WordPress into [YOUR_PEAR_DIRECTORY]/PHP/CodeSniffer/Standards

Usage

Full details of using CodeSniffer can be found at the CodeSniffer site. To use the WordPress Coding Standard you can specify it as an argument:

phpcs --standard=WordPress your-file.php

Alternatively you can set the WordPress Coding standard to be your default:

phpcs --config-set default_standard WordPress

Caveats

Please note that the WordPress standard is not foolproof and it can be very (very) pedantic. It is currently in a very early state and is being released in the hope that others may contribute.

18 comments

  1. Pingback: WordPress CodeSniffer — Matt Mullenweg
  3. Pingback: Scott Jarkoff :: WordPress CodeSniffer Standard
  4. Pingback: WordPress CodeSniffer Standard | Urban Giraffe

  8. Hi there,

    I started trying to get this working with a recent version of CodeSniffer, and it looks like you now need to have a ruleset.xml file for CodeSniffer to detect the new standard when you call `phpcs -i`.

    Also, which docs were you basing the construction of the new WordPress standard on?

    I can’t seem to find any docs on the PEAR site advising how to convert it from the php based approach to (presumably) newer ruleset based standard, and they’d be really helpful for getting it into shape for running these checks as pre-commit hooks when working with git.

    Thanks

      1. Hi John,

        After a bit of poking around, I got this working with project-specific rulesets here, pulling in WordPress’s standards rule by rule, to help when making new projects, and documented how I did it on github here.

        https://github.com/mrchrisadams/Wordpress-Coding-Standards

        Next step is to get this running as a pre-commit hook, on a current wordpress project at work, will update once I’ve got that going here.

        Thanks again for putting in the initial work!

          1. Did the original archive linked from this page get updated with Chris’s improvements?

            Can these sniffs be “ratified” by someone from the core development team (since the WP Coding Standards page doesn’t cover all of the sniffs used), such that they can become “official” and be used by developers to check against with confidence?

  9. I’ve run into a bug in your code… but I don’t know CodeSniffer well enough yet to fix it.

    When I apply PHPCS using your definition to code like the following:

    $arrayName = array(
    ‘abc’ => ‘123’,
    ‘def’ => ‘456’,
    ‘ghi’ => ‘789’
    );

    It throws a ‘Each line in an array declaration must end in a comma’ error.

    I believe it’s in Sniffs/Arrays/ArrayDeclarationSniff.php around line 428:

    if ($tokens[$index[‘value’]][‘code’] !== T_ARRAY) {
    $nextComma = $phpcsFile->findNext(array(T_COMMA), ($index[‘value’] + 1));
    if (($nextComma === false) || ($tokens[$nextComma][‘line’] !== $tokens[$index[‘value’]][‘line’])) {
    $error = ‘Each line in an array declaration must end in a comma’;
    $phpcsFile->addError($error, $index[‘value’]);
    }

    Can you offer any suggestions on how to resolve this?

    1. Put a comma at the end of the ‘ghi’ => ‘789’ line – it’s better practice to save you missing a comma if you extend the array.

  10. I’m using CodeSniffer 1.3 which doesn’t use the wordpress sniffer class. Instead in version 1.3 it looks for a file called ruleset.xml which is responsible for specifying sniffs. I created this file and would like to add it to your project. what’s the best way to do that?

    Also in /usr/bin/pear/share/pear/PHP/CodeSniffer/Standards/WordPress/Sniffs/Functions/FunctionCallSignatureSniff.php on line 206
    $expectedIndent = ($functionIndent + 4);
    should be
    $expectedIndent = ($functionIndent + 1);
    as its counting tab characters. the value of 4 thinks its adding 4 spaces, but it’s actually adding 4 tabs

    Hope that helps

Comments are closed.