Code Review en PHP: 8 cosas clave que todo desarrollador debe revisar

Por qué el code review no es solo "cazar bugs"

Imagina que escribes el código perfecto. Funciona, pasa los tests, incluso el cliente está contento. Pero llega el code review con un colega y... empieza. "¿Por qué usas == en vez de ===?", "Este método hace 5 cosas a la vez", "¿Dónde está el manejo de excepciones?". ¿Te suena familiar?

En realidad, el code review en PHP no es una cacería de bugs (aunque también lo es). Es una forma de hacer que el código sea legible, seguro y mantenible. Especialmente en PHP, que en 25 años de evolución ha acumulado muchas "trampas".

En este artículo veremos qué revisar en un code review de PHP para que el código no solo funcione, sino que sea un estándar de calidad. ¿Listo? ¡Allá vamos!

1. Tipado y modos estrictos

PHP 7+ y 8 nos dieron herramientas potentes para controlar tipos. Pero muchos proyectos aún viven en "modo caos".

Qué revisar:

\n
• ¿Están declarados los tipos de argumentos y valores de retorno? Si un método espera int y le pasas un string — es motivo de conversación.
\n
• ¿Tiene declare(strict_types=1); al inicio del archivo? Sin esto, PHP hará conversiones implícitas de tipos, lo que a menudo causa errores ocultos.
\n

<?php\ndeclare(strict_types=1);\n\n// Mal: sin tipos\nfunction calculate($a, $b) {\n    return $a + $b;\n}\n\n// Bien: tipado estricto\nfunction calculate(int $a, int $b): int {\n    return $a + $b;\n}\n?>\n

Consejo para el code review: si ves mixed o array sin especificar — pregunta "¿Qué se espera exactamente aquí?".

2. Seguridad: inyección SQL y XSS

PHP es como una navaja suiza: tiene muchas funciones, y muchas de ellas son peligrosas. Especialmente en código legacy.

Top 3 banderas rojas:

\n
• Concatenación en consultas SQL. Si ves "SELECT * FROM users WHERE id = ".$_GET['id'] — es un grito de auxilio.
\n
• Mostrar datos sin escapar. echo $userInput; — hola XSS.
\n
• Almacenar contraseñas en texto plano. En serio, esto todavía se ve.
\n

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

En un code review de PHP revisa siempre el manejo de datos externos. Cualquier $_GET, $_POST, $_COOKIE debe pasar por filtrado.

3. Seguir los estándares PSR

La comunidad PHP creó los PSR (PHP Standards Recommendations) no por cumplir. Son el idioma que hablan todos los desarrolladores PHP.

Qué debe tener cada PR:

\n
• PSR-12 (estilo de codificación): sangría de 4 espacios, llaves en nueva línea para clases, espacios alrededor de operadores.
\n
• PSR-4 (autocarga): los namespaces deben coincidir con la ruta del archivo.
\n
• Nombres de clases en StudlyCaps, métodos en camelCase, constantes en UPPER_CASE.
\n

<?php\nnamespace App\\Service;\n\nclass UserService  // PSR-4: el archivo debe estar en src/Service/UserService.php\n{\n    public function getUserById(int $id): ?User  // camelCase\n    {\n        // ...\n    }\n}\n?>\n

Truco: si el proyecto no tiene formateo automático (PHP CS Fixer, PHP_CodeSniffer) — ese es el primer punto a mejorar.

4. Complejidad y arquitectura

El buen código se lee como un libro. El malo, como descifrar un manuscrito antiguo.

Qué revisar:

\n
• Longitud del método. Si un método tiene más de 20-30 líneas, es