Artikelformat

Interaktiv: Code Sniffer

Heute gibt es mal einen interaktiven Beitrag. Das soll bedeuten, dass du lieber Leser gefragt bist. Ich stelle mir das mal so vor, dass – sollte dieser Beitrag ankommen – gelegentlich „interaktiv“ Beiträge hier zu finden sind. Du als Leser gibts nicht nur einen Kommentar ab und bereicherst einen technischen Beitrag um dein Fachwissen, sondern du beschreibst einfach wie du arbeitest. Dadurch wird sicherlich bei Themen, die nicht die Lösung haben, gezeigt, welche Alternativen es noch gibt. Sollte es einen Konsenz geben, so kann man sich als Neuling in dem Thema auch sicherer fühlen.

Das heutige Thema ist der PHP Code Sniffer. Dieses Tool wurde hier schon vorgestellt und auch die Integration in den Jenkins CI (the CI server formerly known as Hudson) wurde erklärt. Den CodeSniffer muss man auf irgendeine Art konfigurieren. Jedes Team hat hier sicher seine eigenen Regeln und daher ist heute die Frage:

Wie habt ihr euer Ruleset definiert?

Mein Kommentar hierzu:
Wir hatten zuerst daran gedacht, alle Regeln zu betrachten und eine sinnvolle Untermenge als Regelsatz festzulegen. Da der organisatorische Aufwand zu hoch schien, wurde der kurze Weg gewählt. Das bedeutet der PEAR-Regelsatz wurde genommen und durch ein paar kleinere Änderungen angepasst. So wurde bspw die Position der öffnenden geschweiften Klammer nicht in die neue Zeile, sondern in die gleiche Zeile verlegt (OpeningFunctionBraceKernighanRitchieSniff). Dies ist der bisherige Stil aller unserer PHP-Entwickler und wahrscheinlich durch die Affinität zu Java motiviert. Daneben wurde erlaubt, dass in Kommentaren nicht alle Tags vorhanden sind, die PEAR normal erfordert.

8 Kommentare

  1. Hi Norbert

    Es ist lustig, aber ich habe genau denselben Ansatz gewählt wie du. Zuerst den PEAR Regelsatz als Standard gewählt und danach auf individuelle Bedürfnisse angepasst.

    Ich war nie sicher, ob dieser Ansatz sinnvoll ist und bin deshalb froh, dass zumindest noch jemand anders auch diese Wahl getroffen hat 🙂

    Antworten
  2. Hab selbst mit ner Mischung aus PEAR und Zend angefangen und pass denn so zwischendurch auch immer mal an.

    Antworten
  3. Das scheinen sehr viele so zu machen. Wir sind seit letzter Woche dabei unseren internen style zu definieren. Dazu nahmen wir den Zend Guide her und adaptierten diesen.

    Antworten
  4. Ich habe einen eigenen Standard aus den diversen existierenden Angeboten zusammengeschraubt.

    Zum einen gab’s gewisse Vorgaben von vor meiner Zeit, die im Code teilweise realisiert wurden. Zum anderen waren etliche Dinge irgendwie noch nicht geregelt, so dass es unterschiedliche Varianten gab. Im Zweifel ist es da am einfachsten, einfach die persönliche Präferenz durchzusetzen, alternativ die am meisten angewandte Variante – spart Arbeit beim Korrigieren aller abweichenden Versionen.

    Die daraus resultierende Konfiguration, ergänzt um wenige eigenständige Regeln, die nirgends passend vorgefertigt waren, kommt dann ins SVN und wird genauso versioniert, wie sonstige Software.

    Antworten
  5. Ich denke, dass es nicht „das“ Regelset gibt, sondern immer nur eines, welches sich an den Bedürfnissen des konkreten Projekts orientiert.
    Ist man in der Gestaltung frei, so kann man sicherlich sein Lieblingsset aus der „best practices“ Ecke nutzen.
    Die Definition eines Regelsets halte ich dabei für unproblematisch. Dank der zahlreich vorhandenen Sniffs, hat man sein Wunsch-Set schnell erstellt.

    Baut man auf bestehendem Code auf, so ist man in der Wahl der Regeln bereits ziemlich eingeschränkt – meistens hat man nicht Zeit, die bereits bestehenden 76453 Violations zu beheben, die man um die Ohren gehauen bekommt, wenn man sein Lieblingsset darauf ansetzt. 😉

    Möchte man nur neu hinzugekommenen Code nach den aktuellen Regeln prüfen lassen und Bestandscode ausklammern, dann entsteht aus meiner bisherigen Erfahrung zum Teil nicht unerheblicher Aufwand. CodeSniffer mit entsprechenden exclude Parametern zu befeuern ist nicht immer einfach und manchmal sogar nahezu unmöglich. Hier würde ich mir von CS eine bessere Unterstützung bei der Definition von Aus- oder Einschlusskriterien wünschen, die möglichst wenig speicherhungrig sind.

    Wovon ich generell enttäuscht bin, ist die Fehleranfälligkeit bei Updates. Es ist ziemlich zeitaufwändig eine CI-Installation mit all den erforderlichen Targets wie pdepend, phpcs, phploc, pphunit, phpdoc, usw. lauffähig und aktuell zu halten. Aber das betrifft nicht CS im Einzelnen worum es hier ja geht.

    Antworten
    • Das Regelset gibt es sicher nicht. Aber wie ich aus den bisherigen Kommentaren lese, gibt es gewisse Tendenzen. Christian ist wohl die Ausnahme, da er sich ein eigenes Regelset gebastelt und auch noch programmiert hat. Übrigens sind da interessante Sniffs zu finden 🙂

      Ich habe die Erfahrung gemacht, dass man natürlich bei der initialen Einführung gerne mal seine 50000+ Violations findet. In meinem Fall konnte ich diese aber mit Hilfe von Netbeans und dem recht guten Code-Formatierer in sehr kurzer Zeit die Violations auf unter 10.000 bekommen. Die restlichen konnten dann bei der täglichen Arbeit und mit etwas Motivation auf fast 0 reduziert werden. Übrig blieb am Ende nur Code, der Refactoring-bedürftig war.

      @DSB: Wenn du zu den Updates auch noch die CI-Server-Software nimmst, mit all ihren Plugins, dann ist die Frustration noch größer. Wobei sich hier auch die Frage stellt, ob man immer die aktuellste Version benötigt?

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.