PHP Code Review: 8 wichtige Prüfpunkte für Entwickler

Warum Code Review mehr ist als "Bugs finden"

Stellen Sie sich vor: Sie haben perfekten Code geschrieben. Er funktioniert, besteht alle Tests, sogar der Kunde ist zufrieden. Doch dann kommt das Code Review und der Kollege beginnt: "Warum hier == und nicht ===?", "Diese Methode macht fünf Dinge auf einmal", "Wo ist die Exception-Behandlung?". Kommt Ihnen das bekannt vor?

In Wahrheit ist Code Review bei PHP keine reine Fehlersuche (auch wenn das dazugehört). Es ist eine Methode, um Code lesbar, sicher und wartbar zu machen. Besonders in PHP, wo sich in 25 Jahren Evolution viele "Stolperfallen" angesammelt haben.

In diesem Artikel zeigen wir Ihnen, was Sie bei einem PHP Code Review prüfen sollten, damit Ihr Code nicht nur funktioniert, sondern ein Qualitätsstandard wird. Bereit? Los geht's!

1. Typisierung und strenge Modi

PHP 7+ und 8 bieten leistungsstarke Werkzeuge zur Typkontrolle. Dennoch leben viele Projekte noch im "Chaos-Modus".

Was Sie prüfen sollten:

\n
• Sind Typen für Argumente und Rückgabewerte deklariert? Wenn eine Methode int erwartet, aber ein string übergeben wird – das ist ein Gesprächsthema.
\n
• Gibt es declare(strict_types=1); am Dateianfang? Ohne dies führt PHP implizite Typumwandlungen durch, was oft zu versteckten Fehlern führt.
\n

<?php\ndeclare(strict_types=1);\n\n// Schlecht: keine Typen\nfunction calculate($a, $b) {\n    return $a + $b;\n}\n\n// Gut: strenge Typisierung\nfunction calculate(int $a, int $b): int {\n    return $a + $b;\n}\n?>\n

Tipp fürs Code Review: Wenn Sie mixed oder array ohne Spezifikation sehen – fragen Sie: "Was genau wird hier erwartet?".

2. Sicherheit: SQL-Injection und XSS

PHP ist wie ein Schweizer Taschenmesser: viele Funktionen, und viele davon sind gefährlich. Besonders in Legacy-Code.

Die 3 größten Warnsignale:

\n
• Konkatenation in SQL-Abfragen. Wenn Sie "SELECT * FROM users WHERE id = ".$_GET['id'] sehen – das ist ein Hilferuf.
\n
• Ausgabe von Daten ohne Escaping. echo $userInput; – hallo XSS.
\n
• Speicherung von Passwörtern im Klartext. Ernsthaft, das kommt immer noch vor.
\n

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

Prüfen Sie bei jedem PHP Code Review die Verarbeitung externer Daten. Jeder $_GET, $_POST, $_COOKIE muss gefiltert werden.

3. Einhaltung der PSR-Standards

Die PHP-Community hat PSR (PHP Standards Recommendations) nicht ohne Grund entwickelt. Sie sind die gemeinsame Sprache aller PHP-Entwickler.

Was in jedem PR enthalten sein sollte:

\n
• PSR-12 (Codierungsstil): 4 Leerzeichen Einzug, geschweifte Klammern in neuer Zeile für Klassen, Leerzeichen um Operatoren.
\n
• PSR-4 (Autoloading): Namespaces müssen dem Dateipfad entsprechen.
\n
• Klassennamen in StudlyCaps, Methoden in camelCase, Konstanten in UPPER_CASE.
\n

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

Lifehack: Wenn Ihr Projekt keine automatische Formatierung (PHP CS Fixer, PHP_CodeSniffer) verwendet – das ist der erste Punkt für Verbesserungen.

4. Komplexität und Architektur

Guter Code liest sich wie ein Buch. Schlechter Code dagegen wie die Entzifferung eines alten Manuskripts.

Worauf Sie achten sollten:

\n
• Methodenlänge. Wenn eine Methode mehr als 20-30 Zeilen hat –