When would you choose PHP CS Fixer over PHP_CodeSniffer, or run both, to enforce a PHP team's coding style?

## Two tools, two starting points Both tools tokenize PHP and enforce a coding standard, and both can target PSR-12 or PER Coding Style, but they were designed around different questions. - **PHP CS Fixer** asks *"what should this code look like?"* and rewrites it. Every rule is a fixer. - **PHP_CodeSniffer** asks *"what is wrong with this code?"* and reports it. Its sniffs raise errors and warnings, and its companion `phpcbf` fixes the violations that a sniff knows how to fix. ## Side by side | Aspect | PHP CS Fixer | PHP_CodeSniffer | |---|---|---| | Primary action | rewrite files (`fix`) | report violations (`phpcs`) | | Report-only mode | `check` / `--dry-run`: lists files that would change, `--diff` shows how | the default; `phpcbf` is the fixing companion | | Unfixable checks | none, since every rule must be able to fix | many, such as naming, doc comments or line length | | Configuration | PHP file returning a `Config` | XML ruleset `phpcs.xml.dist` | | Granularity of findings | per file and rule | per message, with error or warning, severity and a sniff code | | Suppression | `@php-cs-fixer-ignore` file annotation (experimental) | `phpcs:ignore` / `phpcs:disable` by sniff code | | Behaviour-changing rewrites | yes, **risky** rules behind `setRiskyAllowed(true)` | not the tool's focus | | Version modernisation | `@PHP8x5Migration` and similar sets | not the tool's focus | | Custom rules | custom fixers written in PHP | custom sniffs written in PHP | ## When PHP CS Fixer is the better fit - The team wants **zero style discussion**: run `fix`, commit, done. - You want to **modernise syntax** as the minimum PHP version rises, using migration sets. - You are willing to adopt **risky** improvements, like strict comparisons or `declare(strict_types=1)`, in a controlled way. - A formatting check in automation should produce a **diff** the author can apply directly. ## When PHP_CodeSniffer is the better fit - The standard includes conventions that **cannot be fixed automatically**, such as naming rules, required doc comments, forbidden functions with no safe replacement, or line-length limits that need a human to break the line. - You need **graded findings**: warnings that inform but do not block, severities, and suppression by exact sniff code. - An existing ecosystem of shared sniff standards already expresses your rules. ## Running both Combining them is common, typically **PHP CS Fixer for layout and modernisation, PHP_CodeSniffer for report-only conventions**. It works only if the tools do not disagree: 1. **Give layout to one tool.** If both enforce brace placement or spacing with slightly different interpretations, `fix` and `phpcbf` will keep rewriting each other's output. 2. **Exclude the overlap** from the other tool. In a phpcs-for-conventions setup, that means leaving the layout sniffs out of the phpcs ruleset (for example by not including a whole layout standard, or by excluding its whitespace and brace sniffs). 3. **Order the steps.** Run the fixer first, then `phpcs`, so the reporter sees formatted code. 4. **Pin both versions**, because an upgrade of either can change what it enforces. ## Output and suppression in practice The two tools also differ in what a failing check tells the author. `php-cs-fixer check --diff` shows the exact patch to apply, which the author can generate locally with `fix`. `phpcs` shows a list of messages with line numbers and, with `-s`, sniff codes that can be excluded in the ruleset or suppressed with `phpcs:ignore`. Line-level suppression is richer in PHP_CodeSniffer; PHP CS Fixer's exceptions work per file, through the `@php-cs-fixer-ignore` annotation or a rule customisation policy in the config, both still experimental, because its model assumes the fix is normally acceptable. ## A useful way to put it in an interview PHP CS Fixer is the better *formatter*; PHP_CodeSniffer is the better *linter for conventions*. Choosing one is fine when the standard is purely about layout. Once the standard includes rules that need human judgement, PHP_CodeSniffer, alone or beside the fixer, is what can report them.