Code review in PHP: what to check and how to give feedback in practice

Introduction: why code review is about growth, not control

Code review in PHP is not an archaic procedure of a manager controlling a subordinate. It is a professional dialogue between developers aimed at improving code quality, spreading knowledge within the team, and preventing errors at early stages. However, as practice shows, many PHP developers (especially beginners) either fear reviews or turn them into an empty formality.

In this article, we will break down what exactly to look for during a PHP code review, how to formulate comments so as not to offend a colleague, and how to get the most out of this process yourself. The material is based on real experience working on projects using PHP 7.4+ and frameworks like Laravel and Symfony.

1. What to check in PHP code: a practical checklist

There is no universal list, but for PHP projects, 5 key areas can be identified that must be run through the lens of review.

1.1. Security

PHP is a language where it's easy to introduce a vulnerability. First, check:

\n
• SQL injection: Are prepared statements (PDO / prepared statements) used instead of string concatenation?
\n
• XSS (Cross-Site Scripting): Is output escaped using htmlspecialchars() or template engines (Blade, Twig)?
\n
• CSRF protection: Are there tokens on forms that change state?
\n
• Input validation: Is the data type and length checked on the server side?
\n

// Bad: SQL concatenation\n$query = "SELECT * FROM users WHERE id = " . $_GET['id'];\n\n// Good: PDO prepared statement\n$stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');\n$stmt->execute(['id' => $_GET['id']]);\n

1.2. Architecture and SOLID

Even if the project is not enterprise-level, basic principles should be followed:

\n
• Single Responsibility: Does the class/method do too much?
\n
• Dependency Inversion: Does the code use interfaces instead of concrete classes?
\n
• No God Objects: Are there no classes with 1000+ lines?
\n

1.3. Style and PSR Standards

This is critical for PHP. Check compliance with PSR-12 (coding style):

\n
• Indentation — 4 spaces, not tabs.
\n
• Curly braces on a new line for classes and methods.
\n
• Correct naming: camelCase for methods, snake_case for variables (unless otherwise specified in the project).
\n

1.4. Performance

In PHP, it's easy to write slow code. Look for:

\n
• Queries in a loop (N+1 problem) — instead, use Eager Loading in ORM.
\n
• Ignoring cache: repeated calculations of the same data.
\n
• Inefficient functions: for example, in_array() on a large array is better replaced with isset($hash[$key]).
\n

// Bad: query in a loop\nforeach ($users as $user) {\n    $posts = DB::table('posts')->where('user_id', $user->id)->get();\n}\n\n// Good: single query with eager loading\n$users = User::with('posts')->get();\n

1.5. Error Handling and Typing

\n
• Is there strict_types at the beginning of the file?
\n
• Are types used for arguments and return values?
\n
• Are exceptions handled, rather than silenced with a bare try-catch?
\n

2. How to give feedback: from "this is bad" to "let's improve it"

The most difficult skill in code review is not finding an error, but presenting it correctly. Bad feedback kills motivation. Good feedback teaches and brings the team together.

2.1. The "Sandwich" Rule

Fill