Einführung von Coding-Standards
Der vorangegangene Artikel unserer Serie „Erfolgreich Softwareprojekte modernisieren“ befasste sich mit der Einrichtung einer Build Pipeline. Da dort aktuell allerdings noch nicht viel ausgeführt wird, ist es an der Zeit, sich mit dem Coding-Standard, der im Legacy-Projekt verwendet wird, zu befassen.
Coding-Standards, was soll das eigentlich sein? Nähern wir uns diesem Begriff unvoreingenommen, so kann er alle Anforderungen, die Entwicklerinnen an den von ihnen geschriebenen Code stellen, umfassen. Zu diesen Anforderungen können gehören:
Benennung und Positionierung von Dateien im Dateisystem
Benennung von Namespaces, Klassen, Methoden, Funktionen, Parametern und Variablen
Anzahl und Reihenfolge der in Klassen definierten Elemente, wie Konstanten, Felder und Methoden
Anzahl und Reihenfolge der Parameter von Methoden und Funktionen
Länge und Komplexität von Methoden und Funktionen
Typsicherheit von Parametern, Variablen und Rückgabewerten von Methoden und Funktionen
Nichtvorhandensein von Fehlern, die im Rahmen einer statischen Codeanalyse festgestellt werden können
Komposition und Abhängigkeiten von Klassen untereinander
Abdeckung von Code mit Tests
usw.
Im Rahmen dieses Artikels wollen wir uns auf das Aussehen und die Formatierung von PHP-Code zu tun hat. Aber spielt das überhaupt eine Rolle?
Die Maschine
PHP-Code wird im Allgemeinen in vier Schritten ausgeführt. Im ersten Schritt, dem Lexing, wird der Code in sogenannte Tokens zerlegt. Im zweiten Schritt, dem Parsing, werden die Tokens dahingehend validiert, ob ihre Reihenfolge Sinn ergibt, und dann in einen Abstract Syntax Tree geparst. Im dritten Schritt, der Compilation, wird der Abstract Syntax Tree verarbeitet, wobei Optimierungen vorgenommen und schließlich Opcodes erstellt werden. Im vierten und letzten Schritt, der Interpretation, werden die so erstellten Opcodes ausgeführt. Für die Ausführung des PHP-Codes im vierten Schritt sind nur die im dritten Schritt erstellten Opcodes entscheidend. Wird aus zwei unterschiedlichen Varianten von PHP-Code die gleiche Sequenz von Opcodes erstellt, sind diese Varianten offensichtlich funktional identisch. Unterscheiden sich diese Varianten nur in der Formatierung, spielt diese daher für den Interpreter keine (oder nur eine geringfügige) Rolle.
Der Mensch
Die Formatierung von PHP-Code spielt für die an einem Projekt beteiligten Entwickler und Entwicklerinnen hingegen eine deutlich größere Rolle. Um Fehler zu beheben und neue Funktionalitäten umzusetzen, müssen sich die Beteiligten in der Struktur eines Projektes zurechtfinden sowie den vorhandenen Code lesen und verstehen können. Erst dann ist es möglich, nötige Anpassungen vorzunehmen. Das kann umso schneller passieren, je lesbarer der Code ist. Befragt man Entwickler und Entwicklerinnen nach ihren Vorstellungen von lesbarem Code, wird man unterschiedliche Sichtweisen vorfinden. Spaces oder Tabs, und wenn ja, wie viele? Geschweifte Klammern, wohin mit ihnen? Parameter und Argumente alle in eine Zeile oder über mehrere Zeilen verteilen? Erinnert sei hier an die Diskussionen bei der Herleitung von PSR-2, dem mittlerweile überholten Coding Style Guide der PHP Framework Interopability Group (PHP-FIG). Wie bei der Recherche für PSR-2 ermittelt und in den damals folgenden Diskussionen festgestellt, können die unterschiedlichen Sichtweisen gut begründet sein. Häufig sind es persönliche Vorlieben, die man sich über Jahre angeeignet hat. Vermutlich besitzen wir alle einen eigenen (mitunter in sich konsistenten) Stil, Code zu schreiben.
Auswirkungen von Unterschieden in Coding-Standards
Unterschiede zwischen diesen persönlichen Coding-Standards sind natürlich bedeutungslos, wenn nur eine einzelne Person an einem Projekt arbeitet. Sie fallen auch wenig ins Gewicht, wenn voneinander isoliert in Teilbereichen eines Projektes am Code gearbeitet wird. Die Unterschiede können aber zu Problemen führen, wenn Entwickler und Entwicklerinnen gemeinschaftlich an Projekten arbeiten. Hat man sich in einem Projekt nicht auf einen einheitlichen Coding-Standard geeinigt, kann es zu Schwierigkeiten kommen, den vom anderen geschriebenen Code zu verstehen. Weiterhin können sie unsicher sein, wie sie nun ihren Code formatieren sollen: Schnell können Diskussionen um die „richtige“ Formatierung ausarten. Das kann insbesondere dann passieren, wenn einzelne Mitarbeiter und Mitarbeiterinnen bestrebt sind, ihre persönlichen Vorlieben gegen den Widerstand anderer durchzusetzen.
Durchsetzung von Coding-Standards
Am eigenen Leib haben das Menschen erfahren müssen, mit denen der Autor vor Jahren an einem Projekt zusammengearbeitet hat. Der Autor sah sich in diesem Projekt wiederholt bemüht, anderen Entwicklern und Entwicklerinnen in Codereviews abzuverlangen, seine persönlichen Vorstellungen von Coding-Standards umzusetzen. Die Zusammenarbeit mit dem Autor wurde damals recht schnell beendet. Dieser Stress kann aber vermieden werden, wenn die Durchsetzung eines Coding-Standards an Tools übertragen wird, die lokal und in der Build Pipeline ausgeführt werden. Hier und dort können sie auf Fehler hinweisen und im Idealfall diese sogar automatisch beheben. Die Tools können so konfiguriert und erweitert werden, dass die Einstellungen mit den Bedürfnissen eines Teams und der stetigen Weiterentwicklung von PHP wachsen und sich verändern.
Tools
Für PHP gibt es vor allem zwei bekannte, aber recht unterschiedliche Tools. squizlabs/php_codesniffer, entwickelt von Greg Sherwood, ist am 18.09.2006 in Version 0.0.5 erschienen, und zweigeteilt. ...
