Ich habe zwar nächsten Dienstag meine Abschlussprüfungen, aber das Thema Codesniffer brennt mir momentan auf den Nägeln 🙂
In letzter Zeit habe ich mich viel mit Testing und Softwarequalität beschäftigt. Da ich von diesen Themen und Tools überzeugt bin, habe ich sie bedenkenlos eingesetzt. Im Geschäft habe ich auch Jenkins aufgesetzt und betrieben.
Überzeugungsarbeit für den Codesniffer
Ich versuchte stets die Leute in den Projekten davon zu überzeugen, dass sie phpcs (PHP Codesniffer) auf der Konsole vor dem einchecken durchlaufen lassen sollten und dann entsprechend den Fehlern die Korrekturen durchführen sollten. Als sie meine Anweisung mit einem “WARUM?” erwiderten, antwortete ich jeweils, dass der Code so halt einheitlicher und aufgeräumter wirkt.
Warum überhaupt einen Codesniffer verwenden?
Auf einmal fragte ich mich selber, warum man einen Codesniffer einsetzen sollte. Bringt es dem Kunden einen Nutzen, wenn der Code dahinter “schön” und einheitlich aussieht? Ich versuchte also herauszufinden, warum es Sinn ergibt, wenn man sich Standards bei der Formatierung hält.
Ich forschte also ein bisschen nach und bin auf zwei gute Erklärungen gestossen.
Keine Unterbrechung des Flows
Es ist allseits bekannt, dass etwas neues, unerwartetes viel mehr Energie kostet. Genauso ist es bei einem Codestyle, der die ganze Zeit wechselt. Man benötigt neben dem Lösen des Problems noch viel Energie, die verschiedenen Codestyles mental aufzuarbeiten.
Wenn man einen bestimmen Codestyle kennt, kann man sich auf die wahren Probleme konzentrieren. Die Klammern, Einrückungen usw. verschwinden und man konzentriert sich auf die Aufgabe.
Je weniger der Entwickler oder Reviewer gestört wird, desto schneller ist er mit seiner Arbeit fertig. Dies hat also einen positiven Nutzen für den Kunden.
Keine Diskussionen mehr über den Codestyle
Wenn man sich auf einen Standard einigt (z.B. Symfony2, PEAR, Zend, …), so müssen sich die Entwickler nicht mehr darüber streiten, wie Code formatiert werden soll. Dies bringt dem Kunden einen unmittelbaren nutzen, nämlich keine verschwendete Zeit mit Diskussionen über den Codestyle.
Feedback
Was haltet ihr vom Einsatz eines Codesniffers?
Warum sollte man ihn einsetzen oder warum gerade nicht?
Ich würde mich über Feedback freuen!
Man muss nur drauf achten, dass die Umformatiererei nicht die Code-History unlesbar macht. Außerdem wird der Code nicht zwangsläufig aufgeräumter, weil sich dann manch Entwickler darauf zurücklehnt, dass er nicht mehr selbst für Ordnung sorgen müsste, weil das ja ohnehin ein Automatismus übernimmt. Im Ergebnis wird es nicht aufgräumter, weil der Formatter eben nicht in allen Instanzen für lesbare Codequalität sorgen kann. Besonders schlimm finde ich übrigens die Zeilenumbrüche, in denen mir vom Formatter zusammhängende Kommentar- oder Code-Konstrukte umgebrochen werden. Ein inhaltlich durch Menschen erzeugte Ordnung ist nämlich besser, als jene eines stumpfen Algorithmus.
Zur Codehistory:
Wir regeln es bei uns so, dass man Aufräumarbeiten in einem separaten Branch erledigen soll, so dass diese Changes die Reviewer nicht stören.
Automatismus:
Aufräumen muss ja der Entwickler immer noch selber. Es ist einfach einfacher, gewisse Verletzugen des Codestyles zu entdecken, weil er automatisiert ermittelt werden kann. Dann können sich die Reviewer auf die Dinge konzentrieren, die nicht automatisiert ermittelt werden können.
Meiner Meinung nach, es kommt immer drauf an, in was für einem Team man arbeitet und an welchem Projekt.
Ich war eine Zeit lang bei einem Unternehmen beschäftigt, wo es zwar gewisse Codestyles gab, aber daran haben sich irgendwie nicht immer alle gehalten, vor allem nicht die Studenten die eine Praktikum absolviert haben.
Würde man da einen Codesniffer einsetzen, bevor etwas commited wird, würde man noch heute an manchen Umsetzungen sitzen und die Lead-Entwickler sich mit den Studenten rumquälen.
Aber wie gesagt kommt immer auf das Projekt an, ich kenne Unternehmen die Hooks haben, wo kein einziger Commit akzeptiert wird, bevor es nicht durch den Codesniffer durchgejagt wird.
Hi,
generell sollte man Tools benutzen um die Codequalität zu verbessern. Und wenn es nur ist um sich selbst daran zu erinnern auch Dokumentationsblöcke über einer Methode zu erstellen.
Sobald man sich auf einen Standard geeinigt hat, sollten sich alle Entwickler des Teams daran halten. Dies ist dann keine Schikane, sondern hilft auf Dauer allen Entwicklern, vor allem auch wenn neue Entwickler ins Team kommen.
Ich persönlich arbeite in der Firma mit Netbeans und dem phpcsmd Plugin (http://plugins.netbeans.org/plugin/42434/phpcsmd).
Privat benutze ich PHPStorm 5 und nutze die vordefinierten PSR1/PSR2 Standards.