Clean Code in PHP: Leitfaden für professionelle Entwickler

Einleitung: Warum „Clean Code“ nicht nur Pedanterie ist, sondern Zeit und Geld spart

Stell dir vor, du öffnest ein altes PHP-Projekt, das vor einem Jahr geschrieben wurde. Du rufst die Datei index.php auf – und siehst ein Durcheinander aus HTML, SQL-Abfragen, echo-Befehlen und Funktionen mit Namen wie f1(). Kommt dir bekannt vor? Wenn ja, bist du entweder ein Anfänger, der gerade seine Reise beginnt, oder ein erfahrener Entwickler, der ein „Legacy“-Projekt geerbt hat.

Sauberer PHP-Code ist keine Modeerscheinung und keine Laune des Teamleads. Er ist ein Werkzeug, das Stunden, Nerven und Geld spart. In diesem Artikel zeigen wir dir, wie du deinen PHP-Code von einer „schmutzigen Skizze“ in ein „sauberes Endprodukt“ verwandelst, das dich und deine Kollegen begeistert. Wir sprechen über PSR-Standards, SOLID-Prinzipien, richtige Namensgebung und geben dir echte Beispiele. Los geht's!

1. Die Philosophie von Clean Code: Die wichtigsten Prinzipien

Bevor wir in die Syntax eintauchen, legen wir die Spielregeln fest. Sauberer Code ist Code, der:

\n
• Auch ohne Kommentare verständlich ist (obwohl Kommentare manchmal nötig sind).
\n
• Sich leicht testen lässt.
\n
• Keine Angst vor Refactoring hat.
\n
• Einen einheitlichen Stil im gesamten Projekt einhält.
\n

Robert C. Martin (Uncle Bob) sagte in seinem Buch „Clean Code“: „Der einzige Weg, schnell zu schreiben, ist, gut zu schreiben.“ Wenn du schnell und schlampig schreibst, wirst du in einem Monat zehnmal mehr Zeit fürs Debuggen aufwenden. Lernen wir aus den Fehlern anderer, nicht aus unseren eigenen.

2. PSR-Standards: Dein erster Schritt zur Ordnung

In der PHP-Welt gibt es PSR (PHP Standards Recommendations) – Empfehlungen der Community. Wenn du sie nicht nutzt, machst du dir und deinen Kollegen das Leben unnötig schwer.

2.1 PSR-1 und PSR-12: Basis-Codierungsstil

PSR-1 legt allgemeine Regeln fest, PSR-12 den erweiterten Stil. Hier sind die wichtigsten Punkte:

\n
• Dateien sollten nur <?php oder <?= verwenden.
\n
• Dateikodierung: UTF-8 ohne BOM.
\n
• Klassennamen in StudlyCaps (z. B. UserController).
\n
• Methoden- und Eigenschaftsnamen in camelCase (z. B. getUserName()).
\n
• Einrückung: 4 Leerzeichen (keine Tabs!).
\n

Beispiel für schlechten Code:

<?\nclass user_controller {\n\tfunction Get_User_Name($id) {\n\t\t$name = Db::query("SELECT name FROM users WHERE id=$id");\n\t\treturn $name;\n\t}\n}\n

Beispiel für guten Code (PSR-12):

<?php\n\ndeclare(strict_types=1);\n\nnamespace App\\Controllers;\n\nuse App\\Models\\User;\n\nclass UserController\n{\n    public function getUserName(int $id): ?string\n    {\n        $user = User::find($id);\n        return $user ? $user->getName() : null;\n    }\n}\n

Siehst du den Unterschied? Die zweite Variante liest sich wie ein Buch: Auf einen Blick ist klar, was die Methode macht, welche Datentypen sie erwartet und zurückgibt.

2.2 PSR-4: Autoloading von Klassen

Vergiss require_once in jeder Datei. Nutze Composer und PSR-4. So werden Klassen automatisch über Namespaces geladen. Die Ordnerstruktur sollte den Namespaces entsprechen:

src/\n  App/\n    Controllers/\n      UserController.php\n    Models/\n      User.php\n    Services/\n      PaymentService.php\n

In der composer.json wird das mit einer Zeile konfiguriert:

{\n    "autoload": {\n        "psr-4": {\n            "App\\\\": "src/"\n        }\n    }\n}\n

3. Richtige Namensgebung: Wie du deine Variable nicht $a nennst

Die Namensgebung macht 50 % des Erfolgs aus. Ein schlechter Variablenname kann selbst ein Genie verwirren. Schauen wir uns häufige Fehler an.

3.1 Vermeide Abkürzungen (außer bei offensichtlichen)