Choose a PHP Static Analyzer and Formatter by the Job You Need Done

A clean syntax check is a starting point, not a code-quality verdict. If you want reports about potential bugs or type errors without running the code, choose a static analyzer. If you want consistent coding style and automatic fixes, choose a style tool. Those are separate jobs: a formatter can change how code is written without establishing that it behaves correctly.

Choose the analysis job first

PHPStan and Psalm both belong on the analysis side of that divide, but their stated purposes give you a useful way to start choosing. PHPStan is described as finding bugs without running code; the same source describes Psalm as finding type errors in PHP applications. If the question driving your setup is broadly “what potential bugs should we investigate?”, PHPStan fits its stated purpose. If the immediate concern is type errors, Psalm fits its stated focus.

That is a choice of emphasis, not a claim that either tool detects more issues. Whichever you select, review its findings as reports to investigate. Do not treat a clean report as proof that the application runs correctly, or expect an analyzer to enforce the team’s preferred spacing and layout.

If you still need the earlier step of identifying syntax errors, see [Check a PHP File for Syntax Errors Before You Run It](Check a PHP File for Syntax Errors Before You Run It). This choice begins after that question; it does not replace it.

Choose the style rules before the fixer

For style, decide what the project intends to enforce before turning on automatic changes. PHP CS Fixer detects and fixes coding-style issues. Its built-in rule sets include @PER-CS, @Symfony and @PhpCsFixer, and it allows a team to define its own style through a configuration file. Pick a built-in set when it matches the project’s convention; use team configuration when the convention needs to differ. A successful fix against the wrong rules is still the wrong edit for your project.

The other route here is PHP_CodeSniffer (PHPCS) for linting style and PHP Code Beautifier and Fixer (PHPCBF) for fixable validation errors. This pair is worth considering when the project already has a PHPCS standard that contributors should use in their editors. In the VS Code workflow below, linting and fixing are deliberately different actions: saving runs PHPCS, while the documented formatting commands invoke PHPCBF. That makes it easier to inspect what the style fixer changed rather than mistaking a quiet editor for a static-analysis result.

If you select PHP CS Fixer, its documented recommended installation is as a Composer development dependency:

composer require --dev friendsofphp/php-cs-fixer

That command installs the style tool; it does not choose a project ruleset or install an analyzer. Settle the intended style with the team before applying fixes across files.

Connect a PHPCS choice to VS Code

For a project using PHPCS and PHPCBF, the phpSniffer VS Code extension documents PHPCS linting and PHPCBF formatting through Format Document or Format Selection for PHP. PHP and PHP_CodeSniffer must already be installed. This small workspace-settings example tells the extension to look for project-local executables and to lint on save:

{
  "phpSniffer.autoDetect": true,
  "phpSniffer.executablesFolder": "",
  "phpSniffer.run": "onSave"
}

Automatic detection uses ./vendor/bin/ for each workspace folder only when phpSniffer.executablesFolder is empty. The onSave value controls when PHPCS runs; it does not itself request a PHPCBF fix. Use the documented formatting commands when you want a fix, then inspect the resulting edits.

Make sure those checks use the intended workspace standard. When an explicit linting standard is not set, the extension says PHP_CodeSniffer looks at the root of the open file’s workspace folder, in this order: .phpcs.xml, phpcs.xml, .phpcs.xml.dist, then phpcs.xml.dist. Put the project’s intended standard where that discovery will find it, or configure the standard explicitly. Otherwise, the editor may run a style check without applying the rules you meant to enforce.

Do not transfer compatibility claims between similarly named extensions. The separate PHP Sniffer & Beautifier extension states that it supports the latest stable PHPCS 3.x and does not currently support PHPCS 4.x. That statement applies to that extension; it does not establish the same version boundary for the phpSniffer example above.

Check two outcomes, not one green light

After setup, check that the chosen analyzer produces findings for review separately from any formatter edits. Then confirm that a PHP file saved in VS Code receives PHPCS linting under the intended workspace standard, and that PHPCBF fixes are available through the documented formatting commands. Review those changes as style changes—not as resolutions to every analysis finding. Neither a clean analysis report nor a neatly formatted file proves that the code will run correctly.