Mein Freund Garvin, mit dem ich unter anderem meine Leidenschaft für Brettspiele teile, 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]?
Mich wurmt etwas dass PHP_CodeSniffer und PHP-CS-Fixer unterschiedliche Rulesets bieten, da frage ich mich, ob ich nicht alles mit einem hinbekäme.
Meine Antworten ( #1 , #2 ) waren dem Medium geschuldet stark verkürzt, daher möchte ich sie an dieser Stelle ausformulieren.
Die genannten Entwicklungswerkzeuge PHP_CodeSniffer und PHP-CS-Fixer sowie Psalm und PHPStan haben unterschiedliche Zielsetzungen. Sie verfolgen diese Ziele aber auf die gleiche Weise: durch statische Codeanalyse. Diese ermöglicht es, an und mit Code zu arbeiten, ohne ihn ausführen zu müssen.
Coding Standards
PHP_CodeSniffer war wahrscheinlich das erste Werkzeug für die PHP-Entwicklung, das statische Codeanalyse einsetzte. Auf jeden Fall war es das erste, mit dem ich gearbeitet habe. Greg Sherwood begann im Juli 2006 mit der Arbeit an diesem Werkzeug und im September desselben Jahres wurde die erste Version über PEAR veröffentlicht.
PHP_CodeSniffer konzentrierte sich zunächst ausschließlich auf die Formatierung von Code: Spaces oder Tabs? , öffnende geschweifte Klammern in der nächsten Zeile oder nicht, etc. Und da das Werkzeug als Teil des PEAR-Projekts begann, unterstützte es natürlich auch die Regeln des PEAR Coding Standards .
Der Name PHP_CodeSniffer beschreibt recht gut, was das Werkzeug macht: Es schnüffelt am Code und zeigt, wo es stinkt. Dabei ist es nicht darauf beschränkt, alles zu korrigieren, was es finden kann. Im Laufe der Jahre sind beispielsweise Regeln hinzugekommen, die Softwaremetriken berechnen oder die PHP-Version ermitteln können, die zur Ausführung des Codes benötigt wird .
PHP-CS-Fixer hingegen macht schon durch den Namen deutlich, dass dieses Werkzeug mit seinen Regeln den Code nicht nur untersuchen, sondern auch in Form bringen ("fixen") will: Alles, was dieses Werkzeug beanstanden kann, kann es auch automatisiert reparieren. Dazu gehören unter anderem die Formatierung, die Reihenfolge der Deklaration von Methoden in Klassen, keine unnötigen FQCNs, etc.
Ich persönlich habe von 2006 an und über ein Jahrzehnt lang PHP_CodeSniffer verwendet, bevor ich vor einigen Jahren für die tägliche Arbeit zu PHP-CS-Fixer gewechselt bin. In meinen Open Source-Projekten gibt es eine Konfigurationsdatei für PHP-CS-Fixer. Vor einem Commit in die Versionskontrolle benutze ich PHP-CS-Fixer, um sicherzustellen dass er den konfigurierten Regeln genügt. Ist dies nicht der Fall, so wird der Code automatisch korrigiert. In der CI-Pipeline des Projekts wird PHP-CS-Fixer im so genannten "Dry Run"-Modus ausgeführt. Hierbei wird der Code nicht automatisch korrigiert, sondern Abweichungen von den konfigurierten Regeln werden nur berichtet.
Dass ich PHP_CodeSniffer nicht mehr täglich einsetze, bedeutet jedoch nicht, dass ich dieses Werkzeug gar nicht mehr verwende. Für die statische Analyse von Code im Kontext von Due Diligence , Security Audit oder Guided Refactoring verwende ich nachwievor PHP_CodeSniffer, sowohl mit eigenen Sniffs also auch mit spezialisierten Regelsätzen wie dem oben erwähnten PHPCompatibility.
Mit anderen Worten: Für das Einhalten von Coding Standards verwende ich PHP-CS-Fixer, für die Unterstützung bei Code Reviews greife ich auf PHP_CodeSniffer zurück. Für mich ist diese klare Abgrenzung zwischen den beiden Werkzeugen wichtig.
Statisches Testen
Neben PHP_CodeSniffer und PHP-CS-Fixer fragte Garvin auch nach Psalm und PHPStan. Diese Werkzeuge verwenden statische Codeanalyse, um Fehler zu finden, ohne dass der Code tatsächlich ausgeführt werden muss, z.B. durch automatisierte Tests . Ich werde diese beiden Werkzeuge in einem späteren Artikel behandeln.