Die Schwell- und Richtwerte muss wohl, wie es immer so ist, jeder für sich selbst finden. Jede Anwendung und jedes Team sieht es ja gern etwas anders.

Bei der ‘zyklomatischen Komplexität’ könnte man sagen “jede Funktion mit mehr als 10 Verzweigungen steht mal unter dem ‘Verdacht’ schwer wartbar zu sein. Eine Funktion die 10 PHP Funktionen aufruft und deren Rückgabewerte prüft ist sicher schon nicht ganz trivial. Eine Funktion die das 30 mal macht (oder zuerst 10 ‘preconditions’ prüft und dann einen algo ausführt) ist wohl schon ziemlich sicher hart zu lesen.

Hast du nun Tests die Prüfen ob diese Fehlerbehandlungen wirklich nötig sind (d.h. kannst du Code schreiben der dazu führt das sie angesprungen werden) und den andere lesen können wird dadurch die Wartbarkeit verbessert. Mehr würde ich aus dem CRAP-Index nicht ablesen wollen.

Metriken sind erst mal da, was wir da rein interpretieren ist unsere Sache. Ich bin aber entschieden dagegen zu sagen “Meine Implementierung hat eine CCN von 6, deine eine von 9. D.h. meine ist ‘BESSER’”. Das ist, für mich, weit am Sinn des Werkzeugs vorbei.
(Keine Ahnung ob das deinen Punkt getroffen hat, ich meinte jetzt auch nicht dich persönlich sondern hab die Chance genutzt hier ggf. noch was klarzustellen )

@Timo
Sucht ihr gerade Leute ? Klingt nach einer tollen Codebase die ihr euch da erarbeitet habt ! Ich bin ein bischen neidisch.

Was ich sagen will: Die vorgeschlagen Schwellenwerte für jede Metrik sind imho. für jedes Team und für jedes Projekt anzupassen.
Wenn man ein neues Projekt mit einer langen Laufzeit beginnt das hohe Qualitätsansprüche an sich stellt und die Entwickler diese über den weg dieser Metriken mittragen wollen ist jede “default” Einstellung viel zu hoch.
Beginnt man aber in einem 2,5 Mio Zeilen legacy Projekt langsam solche Werte einzuführen bringt es wenig das die Tools über 60.000 Violations mukieren, hier will man erst einmal die “schlimmsten” Probleme lösen und über die Zeit die Werte senken.

Es ist gerade bei riesigen Codebasen nicht immer möglich alles zu refactoren (vor allem wenn man keine Tests hat) und deswegen kann ‘erst Tests schreiben und wenns immer noch schrecklich aussieht den Code umbauen, sonst erst mal sehen wo noch Baustellen sind’ auch ein Arbeitsablauf sein. Denke ich ?

Für Projekte in denen “100% Code Coverage” gelebt wird ist der CRAP-Index natürlich ziemlich egal da er nur die CCN wiederspiegelt.

In dem hier vorliegenden Grafik-Beispiel ist der doppelte Wert mit „popeligen“ 75% Code-Coverage auch noch in Ordnung, und noch höhere Komplexität soll auch noch akzeptiert werden. Ungeheuerlich!

Um ehrlich zu sein, habe ich in meinem Code Schwierigkeiten, Methoden oder Funktionen zu finden, die überhaupt 20 Zeilen lang sind, geschweige denn eine zyklomatische Komplexität von 20 haben!

Und ich akzeptiere nur Code Coverage von 100%. Wenn meine Unit-Tests richtig arbeiten, decken sie alle denkbaren Fälle ab, wenn aber bei allen denkbaren Fällen trotzdem nicht der ganze Code durchlaufen wird, kann er nur überflüssig sein.

Ich habe allerdings so meine Probleme mit der zyklomatischen und der N-Path Komplexität. Meiner Ansicht nach ist da ein Denkfehler drin. Wenn jemand in PHP (das häufig statt Fehlermeldungen zu liefern einfach FALSE als Rückgabewert gibt) ordentlich arbeitet, muss er viele Rückgabewerte auf potentielle Fehler prüfen. Dazu benötigt er jedes Mal eine Verzweigung.

Sauberer, gut geprüfter Code hat somit automatisch mehr Verzweigungen als schlechter Code, der im Fehlerfall den Leuten um die Ohren fliegt. Damit hat sauberer Code aber automatisch eine höhere “N-Path Komplexität”. Die echte “Komplexität” der Funktion ist trotz größerer Anzahl Verzweigungen aber geringer, weil sie ja robuster ist als ohne.

Als Folge davon ist der CRAP-Faktor für PHP in der Regel nicht aussagekräftig. Er müsste auch berücksichtigen, wie viel Code eine Verzweigung hat. Damit nicht automatisch jeder Error-Stub, der nur eine Exception wirft, genauso hoch gewichtet wird, wie eine Verzweigung welche eine ganze Funktion in 2 Hälften spaltet.

Ich schiebe das Thema Code Metriken schon lange vor mir her und lese auch immer wieder Artikel darüber. Bis jetzt habe ich die Zeit aber noch nicht gefunden, mich mit dem Thema intensiver auseinanderzusetzen.