Cyclomatic Complexity Ranges [geschlossen]

Was sind die Kategorien der zyklomatischen Komplexität? Beispielsweise:

1-5: pflegeleicht
6-10: schwierig
11-15: sehr schwierig
20+: Annäherung unmöglich

Seit Jahren gehe ich davon aus, dass 10 die Grenze war. Und alles darüber hinaus ist schlecht. Ich analysiere eine Lösung und versuche, die Qualität des Codes zu bestimmen. Gewiss ist die zyklomatische Komplexität nicht die einzige Messung, aber sie kann helfen. Es gibt Methoden mit einer zyklomatischen Komplexität von 200+. Ich weiß, dass das schrecklich ist, aber ich bin gespannt auf die unteren Bereiche, wie in meinem obigen Beispiel.

Ich fand dies :

Die oben genannten Referenzwerte von Carnegie Mellon definieren vier grobe Bereiche für zyklomatische Komplexitätswerte:

Methoden zwischen 1 und 10 gelten als einfach und leicht verständlich

Werte zwischen 10 und 20 geben einen komplexeren Code an, der möglicherweise noch verständlich ist. Das Testen wird jedoch aufgrund der größeren Anzahl möglicher Verzweigungen, die der Code annehmen kann, schwieriger

Werte von 20 und höher sind typisch für Code mit einer sehr großen Anzahl potenzieller Ausführungspfade und können nur mit großem Aufwand vollständig erfasst und getestet werden

Methoden, die noch weiter gehen, z. B.> 50, sind sicherlich nicht zu halten

Wenn Sie Codemetriken für eine Lösung ausführen, werden die Ergebnisse bei Werten unter 25 grün angezeigt. Ich bin damit nicht einverstanden, hatte aber gehofft, andere Eingaben zu erhalten.

Gibt es eine allgemein akzeptierte Bereichsliste für die zyklomatische Komplexität?

design programming-practices metrics

— Bob Horn
quelle

Sie haben Daten vom Software Engineering Institute gefunden, einer Organisation, die als führend in der Softwareentwicklung anerkannt ist. Ich verstehe nicht, was Ihre Frage ist - Sie haben eine Bereichsliste für die zyklomatische Komplexität gefunden. Was suchen Sie noch?

— Thomas Owens

Ich habe verschiedene Bereiche gesehen; das war nur ein beispiel. Und MS zeigt "grün" für alles unter 25. Ich habe mich gefragt, ob es eine akzeptierte Bereichsliste gibt. Vielleicht habe ich es dann gefunden.

— Bob Horn

Ich stimme @ThomasOwens zu, aber ich bin froh, dass Sie diese Frage gestellt haben. Ich habe es sowohl als Frage als auch als Antwort bewertet.

— Evorlor

In der 2. Ausgabe von Steve McConnells Code Complete empfiehlt er, dass eine zyklomatische Komplexität von 0 bis 5 in der Regel in Ordnung ist. Sie sollten sich jedoch bewusst sein, wenn die Komplexität im Bereich von 6 bis 10 beginnt. Er erklärt weiter, dass Sie bei einer Komplexität von mehr als 10 eine Umgestaltung Ihres Codes in Erwägung ziehen sollten.

— GibboK

Antworten:

Ich nehme an, es hängt von den Fähigkeiten Ihres Programmierpersonals und nicht zuletzt von Ihren Sensibilitäten als Manager ab.

Einige Programmierer sind überzeugte Befürworter von TDD und schreiben keinen Code, ohne vorher einen Komponententest zu schreiben. Andere Programmierer sind perfekt in der Lage, fehlerfreie Programme zu erstellen, ohne einen einzigen Komponententest schreiben zu müssen. Der Grad der zyklomatischen Komplexität, den jede Gruppe tolerieren kann, wird mit ziemlicher Sicherheit erheblich variieren.

Es ist eine subjektive Metrik; Bewerten Sie die Einstellung Ihrer Code Metrics-Lösung und stellen Sie sie auf einen Sweet Spot ein, mit dem Sie sich wohlfühlen und der zu vernünftigen Ergebnissen führt.

— Robert Harvey
quelle

Einverstanden, außerdem kommt es darauf an, was die Ursache für die Komplexität ist. Eine große switch-Anweisung, die andere Funktionen als Teil einer Zustandsmaschine oder dergleichen aufruft, kann eine sehr hohe Komplexität aufweisen, obwohl sie möglicherweise praktisch trivial zu verstehen ist.

— Whatsisname

Sind große switch-Anweisungen nicht typisch für einen Mangel an OOP-Prinzipien wie Polymorphismus? Zustandsautomaten können auf elegante Weise mit OOP- oder Entwurfsmustern implementiert werden. Nein?

— Bob Horn

Bei einigen Problemen ist "Eleganz" nützlich, bei anderen verwirrt es die Dinge. Es gibt keine Silberkugel.

— Whatsisname

-1 Für "Andere Programmierer sind perfekt in der Lage, fehlerfreie Programme zu erstellen, ohne einen einzigen Komponententest zu schreiben." Sie können den Fehler nicht erkennen, wenn Sie ihn nicht getestet haben.

— Sebastien

@Sebastien: Das Fehlen von Komponententests bedeutet nicht, dass es nicht getestet wurde. Und ja, wenn Sie gut genug sind, ist es absolut möglich, fehlerfreien Code ohne Tests oder einen rudimentären Rauchtest zu schreiben. Zugegeben, diese Leute sind eine seltene Rasse.

— Robert Harvey

Es gibt keine vordefinierten Kategorien und eine Kategorisierung wäre aus mehreren Gründen nicht möglich:

Einige Refactoring-Techniken verschieben lediglich die Komplexität von einem Punkt zum anderen (nicht von Ihrem Code zum Framework oder zu einer gut getesteten externen Bibliothek, sondern von einem Ort zur anderen in der Codebasis). Es hilft, die Komplexität der Zyklomatik zu reduzieren und Ihren Chef (oder jeden, der Präsentationen mit ständig wachsenden Grafiken liebt) davon zu überzeugen, dass Sie Ihre Zeit damit verbracht haben, etwas Großartiges zu schaffen, aber der Code bleibt so schlecht wie zuvor.
Im Gegenteil, manchmal, wenn Sie ein Projekt umgestalten, indem Sie einige Entwurfs- und Programmiermuster anwenden, kann sich die zyklomatische Komplexität verschlechtern, während der umgestaltete Code klar sein muss: Entwickler kennen Programmiermuster (von ihnen wird zumindest erwartet, dass sie sie kennen). Das vereinfacht den Code für sie, aber die zyklomatische Komplexität berücksichtigt dies nicht.
Einige andere Non-Refactoring-Techniken wirken sich überhaupt nicht auf die zyklomatische Komplexität aus, während sie die Komplexität eines Codes für Entwickler erheblich verringern. Beispiele: Hinzufügen relevanter Kommentare oder Dokumentation. Den Code mit syntaktischem Zucker "modernisieren".
Es gibt einfach Fälle, in denen die zyklomatische Komplexität keine Rolle spielt. Ich mag das von whatsisname in seinem Kommentar gegebene Beispiel : Einige große switchAnweisungen können extrem klar sein, und das Umschreiben in einer OOPY-Weise wäre nicht sehr nützlich (und würde das Verständnis des Codes für Anfänger erschweren). Gleichzeitig sind diese Aussagen in Bezug auf die Komplexität katastrophal und zyklomatisch.
Wie Robert Harvey bereits oben sagte , hängt es von der Mannschaft selbst ab.

In der Praxis habe ich Quellcode gesehen, der eine gute zyklomatische Komplexität hatte, aber schrecklich war. Gleichzeitig habe ich Code mit hoher zyklomatischer Komplexität gesehen, aber ich hatte nicht allzu große Schmerzen, ihn zu verstehen.

Es gibt nur kein und kein Tool, das fehlerfrei anzeigt, wie gut oder schlecht ein bestimmtes Stück Code ist oder wie einfach es zu warten ist . Da Sie keine Anwendung programmieren können, die besagt, dass ein bestimmtes Gemälde ein Meisterwerk ist und dass ein anderes weggeworfen werden sollte, weil es keinen künstlerischen Wert hat.

Es gibt Metriken, die vom Design abweichen (wie LOC oder die Anzahl der Kommentare pro Datei), und es gibt Metriken, die einige grobe Hinweise geben können (wie die Anzahl der Fehler oder die zyklomatische Komplexität). In allen Fällen handelt es sich nur um Hinweise, die mit Vorsicht verwendet werden sollten.

— Arseni Mourzenko
quelle

+1 Ich stimme allem zu, was gesagt wurde. Zyklomatische Komplexität oder LOC sind nur Metriken, die Ihnen durch statische Code-Analyse übergeben werden. Statische Analysegeräte sind großartige Werkzeuge, aber es fehlt ihnen der gesunde Menschenverstand. Diese Metriken müssen von einem menschlichen Gehirn verarbeitet werden, vorzugsweise von einem erfahrenen Programmierer. Nur dann können Sie feststellen, ob eine bestimmte Software unnötig komplex ist.