PHP_CodeSniffer 4.x: PSR12 Checks and Automatic PHP Fixes

What PHP_CodeSniffer Enforces in PHP Source

PHP_CodeSniffer addresses a narrow but common quality-control problem: PHP code can be syntactically valid while departing from the formatting and structural rules agreed by a team. Its `phpcs` command tokenizes PHP files and reports violations of a selected coding standard. The default is PSR12, so a basic file check does not require the team to name a standard first. Teams using another defined convention can select PEAR with `--standard`, while projects with their own `ruleset.xml` configuration can encode that policy instead.

The intended users include developers running checks locally, maintainers reviewing incoming patches, and teams adding a coding-standard gate to continuous integration. The README explicitly points team and CI users toward a project configuration file. That matters because command-line invocations can differ between a contributor's machine and a build server. A checked-in ruleset gives the project a common definition of accepted code without requiring every person to reconstruct the command.

This is a standards checker, not a general-purpose PHP correctness analyzer. Its reported findings concern violations found by the selected sniffs, which are rules that inspect PHP tokens. The repository topics include static analysis, but the documented mechanism remains tokenization against a coding standard. Adopters should not treat a clean `phpcs` result as proof that functions are secure, free of type errors, or free of runtime defects. It answers a formatting-policy question, not every question about program behavior.

Token-Based Checks Behind `phpcs`

The central mechanism is deliberately small. `phpcs` reads PHP source through the tokenizer, applies the sniffs belonging to the chosen coding standard, and produces a report when it finds violations. A coding standard therefore operates as a collection of rules applied to tokenized input rather than as a separate compiler or source formatter.

This design has a practical consequence. PHP_CodeSniffer can address violations that are visible in source structure and formatting, while the set of possible findings depends on the installed standard and any additional requirements declared by individual sniffs. The README warns that some sniffs may depend on external applications or scripts. Its configuration documentation is the authoritative place to inspect those dependencies before enabling such rules. A team that assumes every distributed sniff is self-contained could encounter a setup failure that is really a missing external dependency.

The `phpcbf` companion uses the same coding-standard context to correct violations automatically. That makes correction different from merely replacing one style preference with another. First, the team must decide which standard governs the file. Second, it must decide which fixes are acceptable in automation. Although the documentation presents `phpcbf` as a normal command, it does not promise that every finding is safely or fully fixable. The report from `phpcs` remains necessary for identifying what the selected rules reject, and review of an automatic-fix diff remains necessary before merging.

Installing `phpcs` and `phpcbf` with PHAR Files

The quickest documented route downloads the two signed PHAR files. PHP 7.2.0 or greater is required. The two commands retrieve the checker and fixer into the current directory; replace either download block with `wget` if that is the available transfer tool.

curl -OL https://phars.phpcodesniffer.com/phpcs.phar
curl -OL https://phars.phpcodesniffer.com/phpcbf.phar

After downloading them, run each PHAR with the help option. Successful execution should present the command's usage information rather than attempting to scan a file.

php phpcs.phar -h
php phpcbf.phar -h

The README says the PHAR files are signed with the official Release key, whose listed fingerprint is `5CB4 F778 BF9B C4FB 67AE 511D 96E9 1A99 2CF2 2FF4`. It also documents verification of release provenance through GitHub Artifact Attestations as of PHP_CodeSniffer 3.10.3. This supply-chain metadata is separate from the source-code license. An organization may require signature or provenance checks before distributing these executables internally.

Project-Local Installation with Composer or Phive

Composer can install the tool globally, but a project-local development dependency is usually easier to reproduce in CI. Add the dependency to `composer.json` as follows. The constraint shown in the README targets the current major version.

{
    "require-dev": {
        "squizlabs/php_codesniffer": "^4.0"
    }
}

Composer then exposes both commands through the project's `vendor/bin` directory. These help calls confirm that the project dependency was installed and that PHP can execute its scripts.

./vendor/bin/phpcs -h
./vendor/bin/phpcbf -h

For team-wide installation, the README also documents `composer global require` and points users to Composer's configured binary directory. That choice is less tightly coupled to the repository because the global package is managed outside the project dependency file.

composer global require "squizlabs/php_codesniffer=*"

Phive offers another project-local layout, with installed tools placed under `tools`. The documented key parameter matches the PHAR signing key after spaces are removed. After both commands succeed, invoke the generated tools through their local paths.

phive install --trust-gpg-keys 5CB4F778BF9BC4FB67AE511D96E91A992CF22FF4 phpcs
phive install --trust-gpg-keys 5CB4F778BF9BC4FB67AE511D96E91A992CF22FF4 phpcbf

This approach avoids assuming that a global executable is present, but it adds Phive as another tool responsible for project setup.

Running the First PSR12 and PEAR Checks

After installation, scan one file against the default PSR12 standard. Supplying a concrete path keeps the first run predictable. If violations exist, `phpcs` prints a report containing them.

phpcs /path/to/code/myfile.php

The same command shape applies to a directory, which is the more common entry point for a project check. The command does not need to be rewritten for recursive directory input.

phpcs /path/to/code-directory

To use PEAR instead, select it with the documented option. This is also the appropriate test for whether adopting an existing convention requires widespread source changes.

phpcs --standard=PEAR /path/to/code-directory

Before putting any scan into CI, inspect the report rather than immediately declaring the codebase compliant. Standards can expose formatting debt in files that were previously valid PHP. Running the check on a representative branch or changing set also reveals how noisy its findings are in the project's actual codebase. The README does not document exit-code handling, inline suppression, baseline files, or a rollback procedure, so it should not be inferred that such workflows are available or expected.

For automatic correction, run `phpcbf` against the same kind of target and review the resulting diff. The documentation confirms that `phpcbf` fixes coding-standard violations, but it does not promise context-free correction for every rule. Version control remains the concrete boundary between a proposed automatic edit and an accepted source change.

PHP 7.2 Support, 4.x Breaking Changes, and BSD-3-Clause

The current repository is not archived, and its last push was on 2026-10-08. Recent releases include 4.0.4 and 4.0.2 on 2026-08-06, as well as 3.13.6 on the same date. The README says the project is tested on PHP 7.2 through PHP 8.5. This gives a broad documented runtime range, but organizations should still verify their own extension requirements through the linked Requirements manual page.

Upgrade planning matters because PHP_CodeSniffer follows `MAJOR.MINOR.PATCH`. A major release can contain backwards-incompatible changes to command usage, `ruleset.xml` format, the sniff developer API, custom token removal, or removal of existing sniffs. A team moving from 3.x to 4.x should therefore review changes affecting its commands, rulesets, custom sniffs, and any scripts that depend on the developer API. Pinning the project dependency, as the `^4.0` Composer constraint does within that major line, gives the project an explicit upgrade boundary.

The repository is licensed under BSD-3-Clause. That matters for organizations examining redistribution and integration, but the project material does not provide legal interpretation or a separate commercial licensing policy. Maintainers should read `licence.txt` for the actual terms and preserve required notices where applicable.

PHP_CodeSniffer is a better fit than an ad hoc formatting wrapper when teams need a named CLI, selectable standards, token-aware rules, and an automatic fixer. A repository-specific formatter may be preferable when only one deterministic formatting workflow is needed. Neither approach should be described as a complete substitute for static analysis, type checking, tests, or security review. PHP_CodeSniffer's boundary is explicit: it reports and corrects violations represented by the selected coding standard.

Editorial conclusion

PHP teams that want enforceable PSR12, PEAR, or custom rules should consider PHP_CodeSniffer 4.x, while projects that need broad semantic bug detection should keep a separate static analyzer in the toolchain. Before adoption, verify the selected ruleset against existing source, confirm that PHP 7.2 or newer is available, and test which findings `phpcbf` changes. The first concrete acceptance decision is whether automatic edits produce an acceptable diff under the project's version control policy.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. PHPCSStandards/PHP_CodeSniffer on GitHub
4. README
5. Releases