Refactoring des Example Projekts

Codesniffer im Projekt nutzen



Bei aller Freude über die erfolgreiche Installation wollen wir den eigentlichen Antrieb, die monotonen Arbeiten macht phpUnderControl für uns, nicht vergessen. Es wird Zeit mal wieder Quellcode zu bearbeiten.
2. Meilenstein

  • der Codingstyle für Codesniffer wird auf “Zend” festgelegt
  • Refactoring: Code Style

Wir legen den Zend Style für unser Projekt einfach fest und lernen ihn dann on the fly.

Hier stellt sich gleich mal die Zwischenfrage: Sollte man den Codesniffer in die Versionverwaltung integrieren und “schlechte” Commits verhindern? Es kommt mal wieder auf die Rahmenbedingungen an. Codesniffers Speicherbedarf steigt mit dem Projektvolumen, zeitkritische BugFixes, Einsatz externer Tools alles das lässt sich geschickt administrieren, aber wollen wir nicht eigentlich coden? Den Spaß am Refactoring gegen den Frust beim Commit abzuwägen ist stark projektabhängig.

Festlegung für das Example Projekt: PhpUnderControl dient zur Kontrolle und keine Sniffer Integration in die Versionsverwaltung.

Welche Codingstyles kennt den CodeSniffer?

Na wenn Zend schon drin ist brauchen wir nur noch den Schalter finden.

Na dann auf zu den Quellen und die Möglichkeiten durchgespielt:

Refactoring beginnt

Da ist noch Refactoring nötig. Holen wir die Übersicht der Stylefehler auf die phpUnderControl Seiten. Den Aufruf von Codesniffer finden wir in der build.xml, leicht zu erkennen als <target name=”php-codesniffer”>

Den Parameter --standard=zend geändert und nach den commit ins CVS Repo sollte der nächste build getriggert werden.

Beim nächsten Build Check sind wir dabei und finden kurz darauf unsere 26 Error(s) im Codesniffer Abschnitt des phpUnderControl. Gz - die erste Änderung in unserem Continuous Integration Prozess.



Die bemängelten Stellen werden wir mal gleich ausbessern. Ich benutze dazu am besten schnell 2 Konsolen.

Nummer 1 zeigt mir alle 5 Sekunden den aktuellen Stand. In der 2. bessere ich den Code aus. Etwas Find&Replace über die Variablennamen mit Ziffern, die langen Zeilen umgebrochen, die Klammerung an den Standard angepasst und plötzlich bleiben die Meldungen in Konsole 1 aus - geschafft.

Publishing

Das nächste CVS Commit sollte unseren Erfolg visualisieren.

cvs commit -m “CS Style erfüllt”

In der Datei habe ich:

Seltsam, die Codesniffer Ausgaben zeigen weiterhin Fehler an, obwohl die Message des Commits im Listing am Ende erscheint.

Aber haben wir den schon die Projektdateien unseres phpUnderControls aktualisieren lassen? Nein, der Bootstrapper hat lediglich die build.xml erneuert. Da war doch was mit XML PingPong - genau in welche SteuerXML soll denn nun der Projektupdate?

Das Projekt kennt seine Dateien besser und welche Versionsverwaltungen auch immer die Entwickler in Zukunft einsetzen wollen, welche Teilprojekte überhaupt aktualisiert werden sollen, alles das können die Entwickler am besten gleich in IHRER projektinternen build.xml verwalten. Ein neues Target muss her:

Dieses Target auch noch ins build integriert als ersten Teil der depends Kette und ein neues commit des Projektes gewagt.

Warten…
Erfolg! Zumindest die Codesniffer Meldungen haben wir beseitigt. Das komplette Build steht zwar noch auf rot, aber jetzt kann uns nichts mehr stoppen. Der nächste Meilenstein wartet.

Nützliche Links:

ANT Manual
CruiseControl Config
CodeSniffer
Deutsche ausführliche Anleitung von Nils Langner (PHP hates me)

Aktualisiert am 24. Mai 2009