Psalm oder PHPStan?

Mein Freund Garvin fragte vor einiger Zeit auf phpc.social :

Heute habe ich endlich mal mit [PHP_CodeSniffer] und [PHP-CS-Fixer] herumgespielt und selber eingerichtet&konfiguriert. So richtig klar ist mir immer noch nicht warum es dafür zwei Tools bedarf, und warum beide quasi gleich abgekürzt werden. phpstan kriege ich ja noch abgegrenzt. Und möchte/muss ich mich auch noch mit [Psalm beschäftigen]?

Ich habe bereits zu PHP_CodeSniffer und PHP-CS-Fixer geschrieben, aber ich habe noch keine Antwort zu Psalm und PHPStan gegeben. Das möchte ich jetzt nachholen.

Psalm und PHPStan sind Werkzeuge für die statische Codeanalyse. Diese hat sich zu einem unverzichtbaren Bestandteil in der PHP-Entwicklung entwickelt. Als Entwickler mehrerer Tools für die statische Codeanalyse habe ich diese Entwicklung hautnah miterlebt und möchte meine Erfahrungen und Erkenntnisse aus über zwei Jahrzehnten Arbeit mit diesen Technologien teilen. Die Reise von den Anfängen von PHP 4 bis zu den hochentwickelten Analysewerkzeugen von heute spiegelt nicht nur die technische Entwicklung der Sprache wider, sondern auch die zunehmende Relevanz von Codequalität und Sicherheit in der Softwareentwicklung.

Grundlagen

Bei der statischen Codeanalyse wird Quellcode ohne dessen Ausführung untersucht, um potenzielle Probleme, Schwachstellen und Qualitätsmängel zu identifizieren. Mithilfe dieser Technik können Entwickler:innen Fehler bereits in frühen Entwicklungsphasen entdecken, wenn deren Behebung noch vergleichsweise kostengünstig ist. Im Gegensatz zur dynamischen Analyse, bei der das laufende Programm untersucht wird, arbeitet die statische Analyse ausschließlich mit dem Quellcode. Daher kann sie bereits vor der ersten Ausführung des Programms wertvolle Erkenntnisse liefern.

In der Zeit von PHP 3 und PHP 4 waren reguläre Ausdrücke das einzige, wenn auch nicht wirklich geeignete Hilfsmittel, das PHP für die Analyse von PHP-Code zur Verfügung stellte. Mit PHP 5 führte die Tokenizer-Extension einen neuen Ansatz ein: Das Ergebnis der lexikalischen Analyse, dem ersten Schritt der Kompilierung von PHP-Code, konnte nun für die Entwicklung statischer Codeanalysewerkzeuge genutzt werden.

Während sich die meisten frühen Werkzeuge mit den bereitgestellten Tokens begnügten, begannen erste Tools bereits damit, vollständige Parser für PHP-Code in PHP zu implementieren. Diese fortschrittlicheren Werkzeuge führten ihre Analysen auf Datenstrukturen durch, die bereits abstrakten Syntaxbäumen sehr nahekamen.

Den entscheidenden Durchbruch brachte jedoch Nikita Popov mit der Veröffentlichung von PHP-Parser. Diese Bibliothek bietet einen vollständigen, in PHP implementierten Parser für PHP-Code. Damit schuf er eine robuste und nachhaltige Grundlage für die Entwicklung professioneller Werkzeuge zur statischen Codeanalyse.

Die Ära von PHP_Depend und PHP Mess Detector

Zu Zeiten von PHP 5 waren PHP_Depend und PHP Mess Detector die dominierenden Werkzeuge für die statische Codeanalyse.

PHP_Depend analysiert den Code und erstellt detaillierte Berichte über verschiedene Qualitätsmetriken, darunter Kopplung, Kohäsion, Vererbungstiefe und zyklomatische Komplexität. PHPMD baut auf PHP_Depend auf und fungiert als Frontend für die von PHP_Depend gemessenen Rohdaten. Es implementiert eine Vielzahl von Regeln zur Erkennung von Code-Smells und potenziellen Problemen, darunter mögliche Bugs, suboptimaler Code, überkomplizierte Ausdrücke und ungenutzte Parameter, Methoden oder Eigenschaften.

Der Übergang von PHP 5 zu PHP 7 brachte erhebliche Änderungen in der Sprachsyntax mit sich, mit denen viele existierende Tools für die statische Codeanalyse zu kämpfen hatten. Sowohl PHP_Depend als auch PHPMD hatten anfangs Schwierigkeiten mit den neuen Sprachfeatures von PHP 7.

Dies führte dazu, dass viele Entwickler, mich eingeschlossen, nach Alternativen suchten oder vorübergehend auf statische Codeanalyse verzichteten. Die Community war gezwungen, neue Tools zu entwickeln oder bestehende grundlegend zu überarbeiten. Mittlerweile werden sowohl PHP_Depend als auch PHPMD wieder (mehr oder weniger) aktiv gepflegt und unterstützen moderne PHP-Versionen. Der Vertrauensverlust während der Übergangszeit hatte jedoch langfristige Auswirkungen auf ihre Akzeptanz.

PHAN

Mit der Veröffentlichung von PHP 7 und dessen verbessertem Typsystem entstand der Bedarf für Tools, die diese neuen Funktionen nutzen konnten. PHAN war eines der ersten Tools einer neuen Generation, das speziell für die erweiterten Möglichkeiten des Type Checkings entwickelt wurde. Es wurde von Rasmus Lerdorf, dem Erfinder von PHP, initiiert, wodurch es von Anfang an eine besondere Bedeutung in der Community hatte.

Während meiner kurzen Zeit mit PHAN war ich von dessen Möglichkeiten, insbesondere beim Type Checking, beeindruckt. Das Tool war in seinen frühen Versionen jedoch noch nicht vollständig ausgereift und hatte gelegentlich Probleme mit komplexeren Codestrukturen. Die Konfiguration war manchmal umständlich und die Dokumentation noch nicht so umfassend. Trotz dieser Einschränkungen zeigte PHAN das Potenzial moderner statischer Analyse-Tools auf und legte den Grundstein für die nächste Generation von PHP-Analysewerkzeugen.

Psalm

Die Entdeckung von Psalm stellte einen Wendepunkt in meiner Arbeit mit statischer Codeanalyse dar. Besonders beeindruckt hat mich, wie flexibel sich unterschiedliche Analysestufen konfigurieren lassen: von der pragmatischen Einstellung "Hier handelt es sich um Legacy-Code, mit dem ich bestmöglich umgehen möchte bis hin zum Anspruch "Hier soll moderner, sauberer Code entstehen".

Psalm war das erste Werkzeug, mit dem ich eine Baseline für Probleme in meine Projekte eingeführt habe. Diese Funktionalität ermöglicht es, existierende Probleme zu dokumentieren und sich auf neue Probleme zu konzentrieren. Das erleichtert die Integration in Legacy-Projekte erheblich, da eine sofortige Behebung aller identifizierten Probleme unpraktisch und wirtschaftlich nicht sinnvoll wäre.

Während meiner jahrelangen Nutzung von Psalm hat sich das Tool kontinuierlich weiterentwickelt und ist zu einem unverzichtbaren Bestandteil meines Entwicklungsworkflows geworden. Die Konfigurationsmöglichkeiten von Psalm sind außerordentlich flexibel, sodass sich das Tool an die spezifischen Bedürfnisse verschiedener Projekte anpassen lässt. Die verschiedenen Error Levels erlauben es, die Strenge der Analyse schrittweise zu erhöhen, was besonders bei der Integration in bestehende Projekte hilfreich ist.

Die Community rund um Psalm war aktiv und hilfsbereit und die Dokumentation war umfassend und gut strukturiert. Das Tool unterstützte eine Vielzahl von PHP-Features und wurde regelmäßig aktualisiert, um neue Sprachfeatures zu unterstützen.

PHPStan

Anfangs ignorierte ich PHPStan , da ich mit Psalm zufrieden war. Die Entwicklungen in der PHP-Community zwangen mich jedoch schließlich dazu, meine Position zu überdenken. PHPStan entwickelte sich schnell zu einem ernstzunehmenden Konkurrenten und begann, in Bereichen zu punkten, in denen andere Tools Schwächen zeigten. Als die Entwicklungsgeschwindigkeit des Psalm-Projekts nachließ und PHPStan gleichzeitig immer mehr an Fahrt aufnahm, wurde es zunehmend schwieriger, dessen Vorteile zu ignorieren.

Was PHPStan wirklich auszeichnet, ist sein umfangreiches Ökosystem an Plug-ins und Erweiterungen. Für praktisch jedes populäre PHP-Framework und jede Bibliothek existieren spezialisierte PHPStan-Extensions, die frameworkspezifische Patterns und APIs verstehen. Dieses Plugin-Ökosystem macht PHPStan zu einem äußerst vielseitigen Tool, das sich an verschiedene Entwicklungsumgebungen anpassen lässt. Ob Laravel, Symfony, WordPress oder andere Frameworks: Für die meisten existieren optimierte Extensions, die die Analyse erheblich verbessern. Durch diese communitygetriebene Entwicklung liefert PHPStan in vielen spezialisierten Bereichen bessere Ergebnisse als generische Tools.

Die Konfiguration von PHPStan ist intuitiv und gut dokumentiert, was die Einarbeitung erleichtert. Die verschiedenen Level von 0 bis 10 erlauben es, die Analyse schrittweise zu verschärfen, was besonders bei der Integration in bestehende Projekte hilfreich ist.

Psalm oder PHPStan?

Jedes Werkzeug ist das Ergebnis menschlicher Entwicklung und spiegelt unweigerlich die Ansichten und Philosophien seiner Schöpfer:innen in seiner Funktionsweise wider. Dies wird besonders deutlich, wenn mehrere Tools für dieselbe Aufgabe, beispielsweise die statische Codeanalyse, parallel eingesetzt werden.

Ein anschauliches Beispiel ist die gleichzeitige Verwendung von PHPStan und Psalm in einem PHP-Projekt: Beide Werkzeuge verfolgen das Ziel, die Code-Qualität zu verbessern, doch ihre Regeln können sich widersprechen, wenn sie auf denselben Code angewendet werden. Entwickler:innen stehen dann vor der schwierigen Aufgabe, beide Tools gleichzeitig zufriedenzustellen.

Die scheinbar objektive Natur von Entwicklungstools trügt also. Sie sind vielmehr Ausdruck subjektiver Entscheidungen ihrer Urheber:innen und können in ihrer Koexistenz zu erheblichen praktischen Herausforderungen führen, die sich kaum mehr mit vertretbarem Aufwand lösen lassen.

Was nun? Und wie?

Obwohl Psalm mittlerweile wieder aktiv weiterentwickelt wird, bleibe ich bei PHPStan, da es meine aktuellen Anforderungen optimal erfüllt und das umfangreiche Plug-in-Ökosystem einen erheblichen Mehrwert bietet.

Entwickler:innen, die neu in der statischen Codeanalyse sind, empfehle ich, mit PHPStan zu beginnen, da es eine gute Balance zwischen Funktionsumfang, Benutzerfreundlichkeit und Community-Support bietet. Die Investition in die Einarbeitung zahlt sich schnell aus, da sich die Codequalität und die Entwicklungseffizienz erheblich verbessern.

Letztendlich hängt die Wahl des richtigen Tools von den spezifischen Projektanforderungen, dem Team-Setup und den persönlichen Präferenzen ab. Wichtiger als die Wahl eines bestimmten Tools ist jedoch die Entscheidung, statische Codeanalyse überhaupt zu verwenden. Die Vorteile, von der frühen Fehlererkennung über verbesserte Codequalität bis hin zu erhöhter Sicherheit, sind so signifikant, dass kein professionelles PHP-Projekt darauf verzichten sollte.

Doch egal, ob PHPStan oder Psalm: Die erfolgreiche Einführung statischer Codeanalyse in einem Team erfordert sorgfältiges Change Management und Schulungen. Wichtig ist, alle Teammitglieder über die Vorteile und die Funktionsweise der Tools zu informieren und gemeinsame Standards für die Behandlung von Analyseergebnissen zu etablieren. Die Definition klarer Prozesse für die Behandlung von False Positives und die Anpassung von Regeln ist essenziell für die langfristige Akzeptanz.

Regelmäßige Reviews der Tool-Konfiguration und der gefundenen Probleme helfen dabei, die Analyse kontinuierlich zu verbessern und an sich ändernde Projektanforderungen anzupassen. Die Investition in Schulungen und Workshops zahlt sich langfristig aus, da gut ausgebildete Entwickler die Tools effektiver nutzen und bessere Ergebnisse erzielen können.

Ausblick

Die Zukunft der statischen Codeanalyse für PHP sieht vielversprechend aus: Es gibt kontinuierliche Verbesserungen bei der Analysepräzision und der Benutzerfreundlichkeit. Machine Learning und KI-basierte Ansätze werden zunehmend in statische Analysewerkzeuge integriert, was das Potenzial für noch präzisere und kontextbewusste Analysen eröffnet. Diese Technologien könnten dabei helfen, die Rate von False Positives weiter zu reduzieren und neue Arten von Problemen zu identifizieren.

Auch die Entwicklung von PHP selbst, insbesondere die kontinuierliche Verbesserung des Typsystems, wird neue Möglichkeiten für die statische Analyse eröffnen. Mit jedem PHP-Release werden neue Sprachfeatures eingeführt, die von Analysetools verstanden und genutzt werden müssen. Eine enge Zusammenarbeit zwischen den Entwickler:innen von PHP und den Entwickler:innen von Werkzeugen wie PHPStan oder Psalm wird entscheidend sein, um sicherzustellen, dass neue Features optimal unterstützt werden.