Dateiübergreifende Code-Analyse

Da PHP keine Compilersprache ist, fällt viel Aufwand bezüglich Übersetzung des Quellcodes weg (“Ich kann nicht arbeiten, er kompiliert…”). Andererseits werden so natürlich aber auch Fehler nicht gefunden, wenn man die Datei nicht offen hat und PhpStorm somit keine Analyse fährt. Während man z.B. in Visual Studio mit dem ReSharper-Plugin (Von Jetbrains, macht aus Visual Studio eine brauchbare IDE) permanent eine globale Analyse aller Quellcodedateien laufen lassen kann, und somit z.B. beim manuellen Refactoring entstehende Fehler in ganz anderen Codeteilen sofort auffallen, ist man in PHP auf manuelle oder besser automatische Tests angewiesen.

Dennoch gibt es in PhpStorm die Möglichkeit, auch über die aktuelle Datei hinaus Inspections laufen zu lassen. Dazu drückt man <Strg>-I, und der Inspection Dialog öffnet sich:

Hier kann man einiges konfigurieren, einerseits den Umfang der Inspektion: Man kann den kompletten Code inspizieren lassen (das macht nur Sinn, wenn man sehr sauberen Code hat, und die Menge der gemeldeten Fehler maximal im zweistelligen Bereich liegt), oder – mein Favorit – alle geänderten, aber noch nicht in die Versionsverwaltung eingecheckten Dateien (“Uncommitted files”).

Das geht dann in Richtung Pfadfinder-Prinzip: Hinterlasse den Code, den Du angefasst hast sauberer, als Du ihn vorgefunden hast. Du kannst nicht die Welt retten, aber wenn jeder ein bisschen macht, dann passiert am Ende viel!

Gleichzeitig kann man auch anfangen, erst einmal einen kleinen Satz Inspections über den gesamten Code laufen zu lassen. Zum Beispiel alle Stellen zu finden, an denen unreachable Code steht. Diese kann man dann beheben, und dann weitere Inspections aufnehmen. Dazu gibt es das Inspection Profile. Man definiert sich einen Satz von Inspections, die man über den Code laufen lassen will, und er prüft nicht die standardmäßig aktivierten, sondern nur die im Inspection Set.

Nach Klick auf “OK” läuft in der Statusbar je nach Anzahl der Inspections und Dateien eine kürzere oder längere Progress-Bar. Man muss aber nicht warten, bis er ganz durch ist, erste Fehler werden direkt schon gruppiert nach Typ der Inspection angezeigt:

Ich kann nun Stück für Stück durchgehen und die Fehler beheben. Gerade bei den durch das Plugin “Php Inspections” (über das ich letzte Woche geschrieben habe) gemeldeten Fehlern gibt es die Möglichkeit gleich mehrere gleiche Fehler in einem Rutsch zu beseitigen:

Hier sind drei identische Probleme zu finden. Ein Rechtsklick auf die Datei bietet hier die spannende Option:

Dies führt nun zu folgendem geänderten Code:

Diese Fehler werden jetzt nicht in den Inspection Results angezeigt – er aktualisiert den View leider nicht in Echtzeit. Das kann man aber mittels des grünen Doppelpfeils nachholen, und wir sehen dann die neuen Fehler:

Auch das könnte ich wieder in einem Rutsch beseitigen, aber spätestens jetzt fällt dem geneigten Leser auf: Das ganze Konstrukt ist sowieso Banane! Hier hat jemand offensichtlich gedacht, dass empty($string) bei Leerstring true ergibt. Dem ist aber nicht so: Empty wirkt anders, wie ein <Strg>-Q auf empty belegt:

Er würde also nur dann null zurückliefern, wenn firstname null oder false ist. Da firstname aber als “?string” definiert ist, macht er firstname genau dann zu null, wenn es schon null ist. Ich ändere also den Code wie folgt:

Und schon tut der Code endlich das, was er tun soll. Danke, PhpStorm und Php Inspections – ich habe einen Fehler gefunden, den ich ohne die Inspections tatsächlich übersehen habe.

Und natürlich fällt auf: Warum gab es eigentlich keinen Unit-Test, der diesen Code abgetestet hat? Aber das ist jetzt ein anderes Thema.

 

Ach ja, und falls derjenige mit liest, der diesen Code geschrieben hat: Sorry, no blaming intended! Du hattest Pech, dass ich gerade diese Codestelle vor mir liegen hatte. Und es war einfach zu schön, gleich einen Bug zu finden mit Hilfe des heutigen Themas.

About the author

People Enabler at CHECK24

Comments

  1. “Hier hat jemand offensichtlich gedacht, dass empty($string) bei Leerstring true ergibt”
    Tut es auch. Probier es aus! Die Kurzdoku ist da missverständlich. empty() liefert für alles true, was bei nicht typsicherem Vergleich zu false evaluiert. Vgl. php.net/empty
    Insofern ist gerade jene Warning mit Vorsicht zu genießen – wie so einige der EA Extended PHP Inspections…

Comments are closed.