PHP_CodeSniffer

PHP_CodeSniffer is a coding standards tool. It tokenizes PHP files, checks them against a configured standard, and reports style violations. It also ships with phpcbf, a fixer that can automatically correct many violations.

The maintained package is under PHPCSStandards. Older projects may still mention Squizlabs because that was the original package history.

The two commands

PHP_CodeSniffer gives you two main commands:

• phpcs checks files and reports problems
• phpcbf fixes problems that can be safely fixed automatically

In a Composer project, they are usually run from vendor/bin.

vendor/bin/phpcs src
vendor/bin/phpcbf src

phpcs is for CI and review checks. phpcbf is for local cleanup.

Choosing a standard

PHPCS can check against a named standard such as PSR12.

vendor/bin/phpcs --standard=PSR12 src

To list installed standards:

vendor/bin/phpcs -i

The project may use a custom ruleset instead of a built-in standard.

Ruleset files

Most teams put PHPCS configuration in an XML ruleset file, commonly phpcs.xml or phpcs.xml.dist.

<?xml version="1.0"?>
<ruleset name="Project">
    <description>Project coding standard.</description>

    <file>src</file>
    <file>tests</file>

    <arg name="extensions" value="php"/>
    <arg name="colors"/>

    <rule ref="PSR12"/>
</ruleset>

With a ruleset in the project root, the team can usually run:

vendor/bin/phpcs

and PHPCS will use the project configuration.

Reading a PHPCS report

A report usually identifies the file, line, column, severity, message, and sniff code.

FILE: src/ReceiptFormatter.php
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
 7 | ERROR | Opening brace should be on a new line
--------------------------------------------------------------------------------

The message tells you what style rule was violated. The file and line tell you where to look.

Fixable and non-fixable issues

Some style issues can be fixed automatically by phpcbf. Others need a developer to change the code.

Examples that are often fixable:

• spacing
• indentation
• brace placement
• import ordering
• missing blank lines

Examples that may require human judgement:

• naming choices
• complex line wrapping
• rules that overlap with project-specific architecture
• comments that need rewriting

Run the fixer, then review the diff.

Composer scripts

Projects often expose PHPCS through Composer scripts.

{
  "scripts": {
    "lint:style": "phpcs",
    "fix:style": "phpcbf"
  }
}

Then developers can run:

composer lint:style
composer fix:style

Use the project scripts when they exist because they encode the expected paths and options.

Ignore carefully

Rulesets can exclude files or patterns. Inline ignore comments also exist. Use them sparingly.

Ignoring generated files, cache directories, or vendor code is normal. Ignoring application code because it is inconvenient should be questioned.

If a rule does not fit the project, prefer changing the shared ruleset deliberately rather than scattering local ignores.

What to remember

PHP_CodeSniffer checks code style with phpcs and fixes many style issues with phpcbf. The project ruleset is the source of truth. Run the checker before CI, use the fixer locally, and review the diff after automatic changes.

Before moving on, make sure you can explain the difference between phpcs and phpcbf, and identify where a project stores its PHPCS rules.