Code Review in PHP: 8 Key Things Every Developer Should Check

Why Code Review Is Not About "Finding Bugs"

Imagine: you've written perfect code. It works, passes tests, even the client is happy. But then a colleague comes to the code review and... it begins. "Why is there == here and not ===?", "This method does 5 things at once", "Where is the exception handling?". Sound familiar?

In reality, code review in PHP is not about hunting for bugs (although that too). It's a way to make code readable, secure, and maintainable. Especially in PHP, where over 25 years of evolution, many "pitfalls" have accumulated.

In this article, we'll break down what to check during a PHP code review so that the code not only works but is a benchmark of quality. Ready? Let's go!

1. Typing and Strict Modes

PHP 7+ and 8 gave us powerful tools for type control. But many projects still live in "chaos mode".

What to check:

\n
• Are argument and return types declared? If a method expects int, but you pass string — that's a talking point.
\n
• Is there declare(strict_types=1); at the beginning of the file? Without this, PHP will implicitly cast types, which often leads to hidden bugs.
\n

<?php\ndeclare(strict_types=1);\n\n// Bad: no types\nfunction calculate($a, $b) {\n    return $a + $b;\n}\n\n// Good: strict typing\nfunction calculate(int $a, int $b): int {\n    return $a + $b;\n}\n?>\n

Code review tip: if you see mixed or array without specification — ask the question "What exactly is expected here?".

2. Security: SQL Injections and XSS

PHP is like a Swiss Army knife: many functions, and many of them are dangerous. Especially in legacy code.

Top 3 red flags:

\n
• Concatenation in SQL queries. If you see "SELECT * FROM users WHERE id = ".$_GET['id'] — it's a cry for help.
\n
• Outputting data without escaping. echo $userInput; — hello XSS.
\n
• Storing passwords in plain text. Seriously, this still happens.
\n

<?php\n// Dangerous!\n$sql = "SELECT * FROM users WHERE email = '" . $email . "'";\n\n// Safe (PDO)\n$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");\n$stmt->execute(['email' => $email]);\n?>\n

During a PHP code review, always check the handling of external data. Any $_GET, $_POST, $_COOKIE must go through filtering.

3. Following PSR Standards

The PHP community created PSR (PHP Standards Recommendations) not just for show. This is the language all PHP developers speak.

What should be in every PR:

\n
• PSR-12 (coding style): 4-space indentation, braces on a new line for classes, spaces around operators.
\n
• PSR-4 (autoloading): namespaces must match the file path.
\n
• Class names — StudlyCaps, methods — camelCase, constants — UPPER_CASE.
\n

<?php\nnamespace App\\Service;\n\nclass UserService  // PSR-4: file should be in src/Service/UserService.php\n{\n    public function getUserById(int $id): ?User  // camelCase\n    {\n        // ...\n    }\n}\n?>\n

Life hack: if the project doesn't have automatic formatting (PHP CS Fixer, PHP_CodeSniffer) — that's the first item for improvement.

4. Complexity and Architecture

Good code is code that can be read like a book. Bad code is like deciphering an ancient manuscript.

What to look for:

\n
• Method length. If a method is longer than 20-30 lines, it's mo