© Nakigitsune-sama/Shutterstock.com
Erfolgreich Softwareprojekte modernisieren – Teil 3

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. E...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang