Code Review in PHP: What to Check and How to Give Feedback for Beginners

Introduction: Why is Code Review Needed in PHP?

Code review is a process where one or more developers check code written by a colleague before it is merged into the main project branch. For beginner PHP developers, this practice can seem intimidating, but it is actually a powerful tool for growth. Code review helps not only to find bugs but also to improve architecture, security, and code readability. In this article, we will break down what to look for when reviewing PHP code and how to give feedback that is useful, not offensive.

1. What to Check in PHP Code: Main Categories

To make the review structured, divide the check into several key areas. This will help you not miss important details and give the author clear recommendations.

1.1. Syntax and Coding Standards (PSR)

The first thing that stands out is the code style. The PHP community has developed PSR (PHP Standards Recommendations) standards that simplify reading and maintaining code. Check:

• Compliance with PSR-12 (indentation, spaces, curly braces).
• Naming of classes (CamelCase), methods and variables (camelCase).
• Absence of extra spaces and blank lines.

Example of bad style:

class userController{function getUser($id){return $id;}}

Example of good style (PSR-12):

class UserController{    public function getUser(int $id): ?User    {        return $id;    }}

1.2. Security

PHP is a language where vulnerabilities are easy to introduce. Pay special attention to:

• SQL injections: use prepared statements (PDO or mysqli), not string concatenation.
• XSS (Cross-Site Scripting): escape output using htmlspecialchars().
• Type checking: use strict typing (declare(strict_types=1);).

Example of insecure code:

$sql = "SELECT * FROM users WHERE id = " . $_GET['id'];$result = mysqli_query($conn, $sql);

Secure version:

$stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');$stmt->execute(['id' => (int)$_GET['id']]);

1.3. Performance and Logic

Check if the code performs unnecessary operations. For example:

• Avoid queries inside loops — use JOIN or subqueries.
• Do not use @ to suppress errors — it hides problems.
• Check that functions do not do too much (single responsibility principle).

Example of slow code:

foreach ($userIds as $id) {    $user = User::find($id); // N queries}

Optimized version:

$users = User::whereIn('id', $userIds)->get(); // 1 query

2. How to Give Feedback: Rules for Beginners

Even if you find many errors, it is important to present the information so that the author does not take it personally. Here are a few principles.

2.1. Be Specific and Objective

Instead of "this code is bad," write: "Line 12 uses SQL concatenation, which can lead to injection. I recommend replacing it with a prepared statement." Explain why it is a problem, not just point it out.

2.2. Use the Feedback Sandwich

Start with a positive comment, then point out the shortcomings, and end with constructive advice. For example:

"Great that you used typing for the arguments! However, the getUser() method returns a string, not a User object — this could break type hinting in other places. I suggest changing the return type to User or null."

2.3. Offer Alternatives, Not Criticism

Instead of "Remove this workaround," su