IPC: Session “Seven Steps to Better PHP Code”
Als erstes war ich heute im Vortrag “Seven Steps to Better PHP Code” von Stefan Priebsch. Völlig überraschend hat Stefan tatsächlich sieben Schritte für besseren PHP Code präsentiert. Es folgt ein Versuch, diese zusammen zu fassen.
Schritt 1: Formatiere deinen Programmcode einheitlich
Nach ein paar Beispielen für schlecht formatierten Programmcode, empfahl Stefan für die eigenen Projekte einen Coding Standard zu etablieren bzw. einen vorhandenen zu nutzen. Zudem sollte man für bestehenden Code einen Code Beautifier verwenden.
Schritt 2: Führe Namenskonventionen ein
Es empfiehlt sich, in seinen Projekten Namenskonventionen für Variablen, Methoden, Klassen, Funktionen und auch für Dateien festzulegen und durchgehend einzuhalten. Nichts ist unnötiger, als den Lesefluss bei einem Programmcode durch nichtssagende Variablen oder Methoden zu verschlechtern. Besonders bei Dateinamen sollte man aufpassen und diese möglichst einfach halten (Buchstaben, Zahlen, Bindestrich, Unterstrich), da es bei Portierung auf andere Betriebssysteme sonst Probleme geben kann.
Schritt 3: Erstelle API Dokumentation
Viele Entwicklungsumgebungen helfen dem Programmierer bereits dabei, alle Funktionen, Klassen, Methoden und Schnittstellen mit Dokumentblöcken und Document Tags auszustatten. Mit Tools wie PHPDoc kann man daraus prima eine API Dokumentation erstellen lassen. In Zukunft sollte dann schon ein Blick in die API Dokumentation ausreichen, um die Funktionsweise zu verstehen.
Schritt 4: Beseitige redundanten Programmcode
Man sollte doppelten oder ähnlichen Code vermeiden, dabei aber aufpassen, dass man es nicht übertreibt und keine über-generalisierten Funktionsmonster erstellt. Bevor man dies macht, sollte man lieber refaktorisieren. Ziel ist es, dass man Codeänderungen nur an einer Stelle vornehmen muss und nicht an 12 verschiedenen Stellen.
Schritt 5: Kürze Codeblöcke
Programmcodeblöcke sollten so kurz wie möglich sein und 700zeilige Codemonster sollten vermieden werden. Der Programmcode sollte lieber in kleinere Einheiten aufgeteilt werden. Dabei gibt es zwei Faustregeln: erstens sollte eine Methode oder Funktion auf eine Bildschirmseite passen und zweitens sollte man jede Methode oder Funktion in 30 Sekunden erfassen können. Ist dies nicht der Fall, ist das Ganze zu komplex und gehört refaktorisiert.
Schritt 6: Trenne verschiedene Belange
Dinge, die nichts direkt miteinander zu tun haben, sollten aufgeteilt werden. Beispiele sind das Dreischichtenmodell oder das Model-View-Controller Entwurfsmuster. Ausserdem sollte man Funktionalitäten wie Hinzufügen, Ändern und Entfernen separieren und auch keinen SQL Code in die Nähe des HTML Codes lassen. Die Trennung vereinfacht das Unittesting, erlaubt die Wiederverwendbarkeit von Code und erleichtert das Lesen des Codes. Stefan hat auch ein schlechtes Beispiel gezeigt, bei dem Datenbankabfragen, Geschäftslogik und die Ausgabe miteinander vermischt wurden.
Schritt 7: Ersetze Implementationen
Hier geht es ans Eingemachte, weil dies vielen Entwicklern schwer fällt. Stefan empfiehlt, wo immer es möglich ist, eigene Komponenten durch externe Komponenten auszutauschen. Statt einer eigenen Mailklasse kann man auch ezcMail oder Zend_Mail verwenden. Manches was vor langer Zeit nicht möglich war, ist heute in PHP selber implementiert. Da lohnt sich ein Blick ins PHP Manual. Generell ist es empfehlenswert auf Komponentensammlungen wie PEAR, eZ Components oder das Zend Framework zurückzugreifen.
Schritt 8: Refaktorierung
Eigentlich kein eigener Schritt, aber Stefan ist zum Schluss noch auf das Thema Refaktorierung eingegangen. Er gab ein paar Tipps, nannte Gründe für das Refaktorieren, erklärte, wann man es am besten macht und vor allem wie man vorgehen sollte.
Alles in Allem war der Vortrag eine gute Zusammenfassung von Tipps, die jeder PHP Programmierer beherzigen sollte, auch wenn man das meiste schon kannte. ABer im Tagesgeschäft vergisst man das ein oder andere immer mal wieder und daher war die Zusammenfassung sehr hilfreich.
Hinterlasse eine Antwort