Statische Codeanalysetools für PHP

... hat jemand damit Erfahrung, weiß vielleicht ein paar Tools zu empfehlen bzw. überhaupt zu nennen? 

Für Java fallen mir da spontan FindBugs, PMD sowie StyleChecker (o.ä.) ein, aber für PHP wird die Luft dünn. NetBeans hat neuerdings Codecoverage (Anweisungsüberdeckung), sowas wäre für Eclipse natürlich auch nicht schlecht.. nur ist eine Anweisungsüberdeckung nicht sehr aussagekräftig ;)

Was ich gefunden, aber noch nicht probieren konnte, das ist PHP-sat. Ich weiß noch nicht, ob das überhaupt den Zweck erfüllt, zumindestens lässt es sich "nicht mal so" installieren. Schade.

• PHP-Sat: http://www.program-transformation.org/PHP/PhpSat

PHPUnit unterstützt auch eine (noch relativ rudimentäre) PMD-Analyse inkl. Code Coverage. Im Pear gibts noch PHP_CodeSniffer was CheckStyle aus Java entspricht. Die Tools schmeissen auch XML-Reports ähnlich der Java-Pendants aus, so dass man sie mit den meisten Aufbereitungstools lesen kann.

Original von exe

PHPUnit unterstützt auch eine (noch relativ rudimentäre) PMD-Analyse inkl. Code Coverage. Im Pear gibts noch PHP_CodeSniffer was CheckStyle aus Java entspricht. Die Tools schmeissen auch XML-Reports ähnlich der Java-Pendants aus, so dass man sie mit den meisten Aufbereitungstools lesen kann.

Ich kenne eine laufende Codesniffer-Instanz, die war nicht genau das/alles was ich suche. Ich kann mir die möglichen Einstellungen angucken, vllt. war da nur nicht alles aktiviert.

PHP-Unit arbeitet dann aber nur mit konkreten Testfällen (bzw. Eingabewerten). Automatisiertes Vorgehen war so mein Wunsch.. evtl sogar auf direkt nicht ausführbaren Code ohne Treiber (Klasse).

xdebug bietet codecoverage statistiken, aber nur für entsprechende bereiche, in denen es mit

xdebug_start_code_coverage()

aktiviert wurde. Würde ich nicht als statisches Codeanalysetool bezeichnen, aber vielleicht kannst du damit trotzdem was anfangen.

Original von knalli

Original von exe

PHPUnit unterstützt auch eine (noch relativ rudimentäre) PMD-Analyse inkl. Code Coverage. Im Pear gibts noch PHP_CodeSniffer was CheckStyle aus Java entspricht. Die Tools schmeissen auch XML-Reports ähnlich der Java-Pendants aus, so dass man sie mit den meisten Aufbereitungstools lesen kann.

Ich kenne eine laufende Codesniffer-Instanz, die war nicht genau das/alles was ich suche. Ich kann mir die möglichen Einstellungen angucken, vllt. war da nur nicht alles aktiviert.

PHP-Unit arbeitet dann aber nur mit konkreten Testfällen (bzw. Eingabewerten). Automatisiertes Vorgehen war so mein Wunsch.. evtl sogar auf direkt nicht ausführbaren Code ohne Treiber (Klasse).

Wie genau stellst du dir das automatisierte Vorgehen denn vor? Das würde ja auf eine Testgenerierung hinauslaufen. Denkst du da an sowas wie Pex (http://research.microsoft.com/en-us/projects/Pex/)?

Also die beiden o.g. Plugins für Eclipse (ich denke, die kann man auch standalone ans Laufen kriegen) scannen den Quelltext - eben statisch (deswegen ja der Name :)).

Die beiden Plugins zeigen die gefundenen Fehler ähnliche wie die Eclipse-Compiler-Fehler mit entsprechenden Warnhinweisen an.. unter Java sind da natürlich weitaus mehr Möglichkeiten gegeben. Beispiele aus der Java-Welt: potenzielle NPE (anders herum: kein Fehler, wenn entsprechend gesichert), synchronize-Problem-Stelle (meist, wenn man bsp. eine Variable "vergessen" hat mit sync o.ä. zu markieren), fehlende finals, fehlende static/Klassennamen, usw.

Statische Codeanalyse prüft den Code nur auf bestimmte Auffälligkeiten, also keine Ausführung des Objektes (Unittest passt da nicht wirklich). Einen statischen Tester hat jeder schon genutzt - das ist nämlich der Compiler.

Sorry, hatte das davor falsch verstanden ;)

Standalone würde mir da ausser CodeSniffer auch nichts wirklich interessantes einfallen. Wobei ich CodeSniffer genau wie CheckStyle aus der Javawelt auch nicht wirklich hilfreich finde. Standardkram wie die Komplexitätstests sind noch relativ einfach, viele andere Tests aus PMD und Findbugs mit einer so wenig typisierten Sprache wie PHP dann eher weniger. Man weiss dann halt doch erst zur Lauftzeit was der Code wirklich macht. Bei z.B. Java lässt sich in einer statischen Analyse dann doch mehr aussagen.

Das Zend Studio weist einen auch auf zig Fehler hin, wenn irgendwelche Variablen benutzt werden, ohne initialisiert zu werden, wenn irgendwelche "üblichen Sicherheitsfehler" begangen werden, etc.

Vielleicht geht das in die Richtung, was du suchst?

ich hielt den PHP-parser immer für ausreichend (mit error-reporting E_ALL | E_STRICT). Der warnt auch bei uninitialisierten variablen, bei komischen konstrukten (z.b. wenn man eine per referenz übergebene funktion/objekt nicht explizit wieder so zuweist. bsp: return foo&; und a = bar(); statt a =& bar();), usw. usf.

ich weiss nicht, was du von so einem tool erwartest.. weil viel mehr als parsen und ein bissl mutmaßen kann man mit statistischen tools nicht.

Naja, ein bisschen geht schon. Beispielsweise würde Zend rummeckern, wenn du eine Datei über eine Variable referenzierst, weil diese ja theoretisch mit irgendeinem anderen, 'bösen' Wert überschrieben werden könnte. Aber so wahnsinnig viel wird statisch auch nicht angezeigt, inkl. dem Debugger geht da schon einiges mehr.

Ähm.. wie gesagt: Das erste statische Testtool ist immer der Compiler.. oder ein Compiler, der "schärfer" eingestellt ist. Aber es geht immer mehr; theoretisch können auch Konventionen überprüft werden (z.B., mehr in Java als PHP, ob Membervariablen auch nie von aussen zugriffen werden => Getter/Setter, oder eben final).

Und: Ein statischer Test ersetzt keinen dynamischen Test (in Ausführung, zur Laufzeit). Es ist aber eine schöne Ergänzung, die idR selbstständig und automatisiert funktioniert. Aus letztem Grunde wäre auch ein Plugin für eine IDE wie Eclipse optimal.

Weswegen ich da überhaupt nachfrage: Ich habe mich mit Testen in den letzten Monaten intensiver beschäftigt, und mir ist aufgefallen, das ich diesbzgl. in PHP wenig habe. Für Java dagegen auf Anhieb sehr wohl.

Zuverlässige statische Analyse Tools wie für Java sind für dynamisch typisierte Sprachen wie PHP so ziemlich ein Ding der Unmöglichkeit, weswegen man so etwas nicht findet.

prinzipiell +1, es sei denn man erlegt sich selbst Grenzen auf und arbeitet konsequent mit striktem typecasting.

ind diesem fall könnte man mit relativ simplen shellscripten unter Verwendung von sed und grep den Code z.B. typkonsistent halten. Laufzeittypsicherheit könnte zwar immer noch nicht garantiert werden, da PHP auch mit striktem typecasting einfach mehr oder weniger sinnvoll casten würde, aber die Scripte könnten z.B. Listen liefern, wo kritische casts erfolgen.

Ob das im Endeffekt die Mühe lohnt lass ich mal dahingestellt.

Klar kann ich mit "simplen Shellscripten" (das ist jetzt ein schlechter Scherz? :D) das auch hinkriegen, aber ich hatte 'mal gehofft, dass irgendjemand das vielleicht schon mal gemacht hat.

PHPLint kann hier auch hilfreich sein, setzt allerdings vorraus das man seinen Code entsprechend kommentiert. Allerdings kann man dann auch gleich in einer statisch typisierten Sprache programmieren denn darauf läuft PHPLint im Grunde hinaus.

Original von knalli

Klar kann ich mit "simplen Shellscripten" (das ist jetzt ein schlechter Scherz? :D) das auch hinkriegen, aber ich hatte 'mal gehofft, dass irgendjemand das vielleicht schon mal gemacht hat.

wieso sollte das ein Scherz sein? Textanalyse und -konvertierung funktionieren mit gängigen Unixtools prima, und wenn dir Programmiersprache das nicht hergibt, muss man halt zu Fuss ran. Die Shellscriptmethodik haben Admins schon angewendet bevor es PHP gab, die Tradition von grep, sed und awk reicht weit zurück. Eleganter noch wär gleich ein vi plugin zu schreiben.

Es gibt schliesslich auch IDE's die sich auf die vorhandenen Unix Werkzeuge stützen, und für eine interpretierte Scriptsprache ist die Methodik abseits des Runtimedebuggings sicher nicht die schlechteste.

Die Frage ist doch: was für Überraschungen gedenkst du, in deinem Code zu finden?

Sry, aber das Nutzen von awk, grep und den anderen Grausamkeiten zur statischen Codeanalyse entspricht dem Nutzen von Webkit, Html und JavaScript zur Steuerung von Atomkraftwerken.

Nur weil es funktionierten könnte, heißt es lange noch nicht, dass es sinnvoll ist. Für eine statische Codeanalyse müssen Ablauf- und/oder Baumstrukturen aufgebaut werden und diese auf Sinnvollhaftigkeit geprüft werden. Du kannst natürlich Unix-like mit diversen Tools darumfrickeln oder gleich einen sauberen Ansatz nehmen, der das Problem selbst behandelt. Ich erwarte von einem solchen Tool, dass er den PHP-Text in seine Token/Mnemonics umwandelt und auf Basis dieses Zwischenschritts Entscheidungen über die Validität fällt. Direkt auf dem Text zu arbeiten, das ist vergebene Liebesmühe.

Mir persönlich sind leider keine Verifikationstools in PHP bekannt, die genau dies tun. Dazu müsste man sich in den Zend-Interpreter einklinken, nachdem er den PHP-Quelltext in seine Tokens umgewandelt hat oder gleich einen eigenen Interpreter schreiben, der dies tut.

http://de3.php.net/token_get_all

Sry, aber das Nutzen von awk, grep und den anderen Grausamkeiten zur statischen Codeanalyse entspricht dem Nutzen von Webkit, Html und JavaScript zur Steuerung von Atomkraftwerken.

Ich hätte nie gedacht dass du mir mal so aus der Seele sprechen würdest. ;)