Skip to content

PHP Tutorial PHP Performance and Best Practices

PHP Coding Standards and Tools

Lesson 345 of 369 3 min read By Deepak Paswan Updated Oct 5, 2026

A coding standard is an agreed set of style and quality rules. The point is not that the rules are perfect, but that everyone follows the same ones, so code looks the same and reviews focus on logic.

You already know the PSR-12 style from Modern PHP Coding Style. This lesson is about tools that enforce standards, so you do not have to remember them.

The standards you will meet

StandardCovers
PSR-1Basic rules (file names, class names)
PSR-12Detailed coding style (replaces PSR-2)
PER Coding StyleThe evolving successor to PSR-12
PSR-4Autoloading (PSR-4 Basics)
WordPress Coding StandardsWordPress style (tabs, snake_case)
Symfony / Laravel conventionsFramework-specific style

EditorConfig

A small .editorconfig file makes every editor use the same indentation and line endings.

php.ini
INI
root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

[*.php]
indent_style = space
indent_size = 4

Style checkers and fixers

ToolWhat it does
PHP_CodeSniffer (phpcs)Reports style violations. phpcbf fixes many of them
PHP CS FixerRewrites code to match a style automatically
Laravel PintA friendly wrapper around PHP CS Fixer
terminal
BASH
composer require --dev squizlabs/php_codesniffer
vendor/bin/phpcs --standard=PSR12 src/
vendor/bin/phpcbf --standard=PSR12 src/

Static analysis

Static analysers read your code without running it and find mistakes: calling a method that does not exist, passing the wrong type, using an undefined variable, dead code.

ToolNotes
PHPStanVery popular. Strictness levels 0 to 9 and a max level
PsalmSimilar, with extra type features
RectorAutomated refactoring and PHP version upgrades
terminal
BASH
composer require --dev phpstan/phpstan
vendor/bin/phpstan analyse src --level=6

Start at a low level and raise it as you clean up. Static analysis is a very cheap way to find bugs before users do.

For example, this code has a bug that no test needs to run to find:

index.php
PHP
<?php
function total(array $items): int
{
    return array_sum($items) . "";   // PHPStan: should return int, string given
}

Syntax check

terminal
BASH
php -l file.php

Checks a file for syntax errors without running it. A one-liner for a whole project:

terminal
BASH
find src -name "*.php" -print0 | xargs -0 -n1 php -l

Tests

Style and static analysis do not prove the code is correct. Automated tests (PHPUnit or Pest) do. Even a few tests on your most important logic catch regressions.

index.php
PHP
<?php
function slugify(string $text): string
{
    return trim(preg_replace("/[^a-z0-9]+/", "-", strtolower($text)), "-");
}

// A tiny self-check, the seed of a real test
$cases = [
    "Hello World" => "hello-world",
    "  PHP & MySQL!  " => "php-mysql",
    "Already-slugged" => "already-slugged",
];

foreach ($cases as $input => $expected) {
    echo slugify($input) === $expected ? "ok " : "FAIL($input) ";
}
Output
OUTPUT
ok ok ok

Run the checks automatically

WhereHow
In your editorFormat on save, show PHPStan and phpcs warnings
Before each commitA Git pre-commit hook that runs the fixer and php -l
On every pushCI (GitHub Actions, GitLab CI) runs phpcs, phpstan and the tests, and fails the build if something is wrong

A minimal composer script keeps the commands short:

data.json
JSON
{
    "scripts": {
        "lint": "phpcs --standard=PSR12 src",
        "analyse": "phpstan analyse src --level=6",
        "test": "phpunit",
        "check": ["@lint", "@analyse", "@test"]
    }
}

Run composer check before you push.

Adopt a standard, then stop arguing

Choose one, write it down (a CONTRIBUTING.md helps), let the tools enforce it, and spend review time on design and correctness.

lightbulb
Introduce tools gradually
On an old codebase, running a fixer over everything creates a huge diff. Apply it to new and changed files first, or in one dedicated commit that everyone agrees on.