Code Style and Linting Essentials

Recap why consistent code style and linting matter for a maintainable PHP test suite, and know when to reach for the dedicated Code Quality Toolchain lesson for full PHP_CodeSniffer/PHP-CS-Fixer depth.

Code that looks different from file to file — mixed indentation, inconsistent brace placement, arbitrary naming — slows every reviewer and every future reader down, including the person who wrote it six months ago. PHP has two workhorse tools for this: PHP_CodeSniffer (PHPCS), which detects and reports style violations against a standard like PSR-12, and PHP-CS-Fixer, which automatically rewrites code to match a configured style. This lesson is a short refresher; for the full lesson on configuring rule sets, running PHPCS/PHP-CS-Fixer in CI, and combining them with Rector and PHPMD, see the dedicated "Code Quality Toolchain" lesson elsewhere in this module.

Linting vs. formatting

Linting and formatting solve related but distinct problems. A linter (PHPCS is PHP's most common one) reports violations of a coding standard — inconsistent indentation, missing type hints, lines that are too long — without necessarily fixing them; some violations (phpcbf, PHPCS's companion fixer) can be auto-corrected, others need a human decision. A formatter (PHP-CS-Fixer) goes further: given a rule set, it rewrites the file in place to match it, so an entire team's code converges on one visual style without anyone manually adjusting whitespace.

The standard almost every modern PHP project targets is PSR-12 (extending the older PSR-1/PSR-2), which fixes things like brace placement, indentation width, and import ordering. Running PHPCS or PHP-CS-Fixer with --dry-run/--diff in CI turns style into a gate: a pull request with inconsistent formatting fails the build instead of relying on a human reviewer to notice and comment on it.

• PHPCS: reports (and partially auto-fixes via phpcbf) coding standard violations. • PHP-CS-Fixer: automatically rewrites files to match a configured style. • PSR-12 is the de facto standard most PHP projects target. • Run style checks in CI with a dry-run/diff mode so formatting is enforced, not just suggested.

Why this matters for a test suite specifically

Test files benefit from style enforcement just as much as application code — arguably more, since tests are read constantly during debugging. Consistent naming conventions for test methods, consistent arrange/act/assert spacing, and consistent import ordering make it faster to scan a failing test and understand what it's checking. Style tools don't understand test semantics, but they remove an entire category of noisy diff (whitespace-only changes) from code review, which is where a human's attention should be on "is this test actually asserting the right thing?" rather than on indentation.

For the complete treatment — configuring PHPCS rule sets and severity, tuning PHP-CS-Fixer's rule list, wiring both into pre-commit hooks and CI, and combining them with Rector for automated refactors and PHPMD for design-smell detection — see the full "Code Quality Toolchain" lesson in this course.

• Style tools eliminate whitespace-only noise from code review. • Consistent test naming and structure make failures faster to diagnose. • See the "Code Quality Toolchain" lesson for full PHPCS/PHP-CS-Fixer/Rector/PHPMD detail.

Code Examples

This config tells PHP-CS-Fixer to enforce the PSR-12 rule set as a baseline, then layer on three extra rules: short array syntax, removing unused use imports, and alphabetizing imports. Running php-cs-fixer fix --dry-run --diff in CI reports any file that doesn't match this exactly, and running it without --dry-run rewrites the files automatically.

'@PSR12' => true, Common mistake: Running the fixer locally but never in CI means style drift creeps back in the moment someone forgets to run it before committing — CI enforcement is what makes the standard stick.

Letting reviewers flag style issues (indentation, brace placement) by hand in every pull request.

Automate style with PHPCS/PHP-CS-Fixer and run it as a required CI check so style is never a discussion topic in review.

Manual style review wastes reviewer time on mechanical issues a tool catches instantly, and it's inconsistent — different reviewers flag different things. Automating it frees reviewers to focus on logic and test correctness.

What is the key difference between PHP_CodeSniffer and PHP-CS-Fixer? A. PHPCS runs tests, PHP-CS-Fixer runs static analysis B. PHPCS primarily reports style violations, while PHP-CS-Fixer automatically rewrites code to match a configured style C. They are the same tool with different names D. PHP-CS-Fixer only works on PHP 5, PHPCS only works on PHP 8

B. PHPCS primarily reports style violations, while PHP-CS-Fixer automatically rewrites code to match a configured style — PHPCS is primarily a reporting/detection tool (with phpcbf handling some auto-fixes), while PHP-CS-Fixer's core job is rewriting files to conform to a configured rule set.

<?php
// .php-cs-fixer.dist.php
$finder = (new PhpCsFixer\Finder())
    ->in(__DIR__ . '/src')
    ->in(__DIR__ . '/tests');

return (new PhpCsFixer\Config())
    ->setRules([
        '@PSR12' => true,
        'array_syntax' => ['syntax' => 'short'],   // [] not array()
        'no_unused_imports' => true,
        'ordered_imports' => ['sort_algorithm' => 'alpha'],
    ])
    ->setFinder($finder);