Suche nach Erklärungen über Strukturierung Code zyklomatische Komplexität zu reduzieren

StackOverflow https://stackoverflow.com/questions/204369

Frage

Vor kurzem hat unser Unternehmen begonnen, die zyklomatische Komplexität Messung (CC) der Funktionen in unserem Code auf einer wöchentlichen Basis, und das Reporting, die Funktionen verbessert oder verschlechtert. So haben wir begonnen, mit dem CC von Funktionen viel mehr Aufmerksamkeit.

Ich habe gelesen, dass CC informell als 1 + in Abhängigkeit der Anzahl von Entscheidungspunkten berechnet werden konnte (zB if-Anweisung for-Schleife, wählen usw.), oder auch die Anzahl der Pfade durch eine Funktion ...

Ich verstehe, dass der einfachste Weg, CC zu reduzieren, ist die Methode extrahiert Refactoring wiederholt zu verwenden ...

Es gibt Somethings Ich bin nicht sicher, z.B. was ist der CC der folgenden Codefragmente?

1) 

for (int i = 0; i < 3; i++)
    Console.WriteLine("Hello");

Und 

Console.WriteLine("Hello");
Console.WriteLine("Hello");
Console.WriteLine("Hello");

Sie beide das gleiche tun, aber nicht die erste Version eine höhere CC hat wegen des für Aussage?

2) 

if (condition1)
    if (condition2)
        if (condition 3)
            Console.WriteLine("wibble");

Und 

if (condition1 && condition2 && condition3)
    Console.WriteLine("wibble");

Unter der Annahme, die Sprache nicht Kurzauswertung, wie C #, dann diese beiden Codefragmente die gleiche Wirkung haben ... aber ist das CC des ersten Fragments höher, weil es drei Entscheidungspunkte hat / if-Anweisungen?

3) 

if (condition1)
{
    Console.WriteLine("one");

    if (condition2)
        Console.WriteLine("one and two");
}

Und 

if (condition3)
    Console.WriteLine("fizz");

if (condition4)
    Console.WriteLine("buzz");

Diese beiden Codefragmente verschiedene Dinge tun, aber haben sie die gleiche CC? Oder ist die verschachtelte if-Anweisung in dem ersten Fragmente eine höhere CC hat? das heißt verschachtelt, wenn Aussagen geistig komplexer zu verstehen sind, sondern dass im CC reflektiert?

War es hilfreich?

Lösung

  1. Ja. Ihr erstes Beispiel hat einen Entscheidungspunkt und Ihre zweite nicht der Fall, so dass die erste eine höhere CC.
  2. Ja, vielleicht, Ihr erstes Beispiel mehrere Entscheidungspunkte hat und damit eine höhere CC. (Erläuterung siehe unten).
  3. Ja, vielleicht. Offensichtlich haben sie die gleiche Anzahl von Entscheidungspunkten, aber es gibt verschiedene Möglichkeiten, um CC zu berechnen, was bedeutet, ...

... wenn Ihr Unternehmen CC in einer bestimmten Art und Weise zu messen, dann müssen Sie mit dieser Methode vertraut werden (hoffentlich verwenden sie Werkzeuge, um dies zu tun). Es gibt verschiedene Möglichkeiten CC für verschiedene Situationen (case-Anweisungen, Boolesche Operatoren, usw.) zu berechnen, aber Sie sollten die gleiche Art von Informationen aus dem metrischen egal bekommen, was Konvention Sie verwenden.

Das größere Problem ist das, was andere schon erwähnt haben, dass Ihr Unternehmen mehr auf CC zu sein scheint konzentriert als auf dem Code dahinter. In der Regel sicher, unter 5 ist groß, unter 10 gut ist, unter 20 in Ordnung ist, 21 bis 50 soll ein Warnzeichen sein, und über 50 sollte ein großes Warnzeichen sein, aber das ist Führer, nicht absolute Regeln. Sie sollten wahrscheinlich den Code in einem Verfahren untersuchen, die eine CC über 50 hat, um sicherzustellen, dass es nicht nur ein großer Haufen von Code, aber vielleicht gibt es einen bestimmten Grund, warum das Verfahren auf diese Weise geschrieben werden, und es ist nicht möglich (für jeden Reihe von Gründen), um es zu Refactoring.

Wenn Sie Tools verwenden, um Ihren Code Refactoring CC zu reduzieren, stellen Sie sicher, dass Sie verstehen, was die Werkzeuge tun, und dass sie einfach nicht ein Problem an einem anderen Ort verschoben werden. Schließlich wollen Sie Ihren Code wenige Fehler zu haben, richtig zu arbeiten, und relativ leicht zu pflegen zu sein. Wenn dieser Code hat auch eine niedrige CC, gut für sie. Wenn Ihr Code diese Kriterien erfüllt und hat eine CC über 10, vielleicht ist es Zeit, mit dem, was Management können Sie sich setzen und den Code zu verteidigen (und sie vielleicht ihre Politik zu untersuchen bekommen).

Andere Tipps

durch den Wikipedia-Eintrag Nach dem Surfen und Thomas J. McCabe Originalpapier , wie es scheint dass die von Ihnen oben erwähnt sind bekannte Probleme mit der Metrik.

Die meisten Metriken haben Vor- und Nachteile haben. Ich nehme an, in einem ausreichend großen Programm des CC-Wert auf möglicherweise komplexe Teilen des Codes zeigen könnte. Aber die höhere CC nicht notwendigerweise komplex bedeuten.

Wie alle Software-Metriken, ist CC nicht perfekt. Auf einer großen genug Code-Basis, kann es Ihnen gibt eine Vorstellung davon, wo könnte eine problematische Zone sein.

Es gibt zwei Dinge im Auge zu behalten hier:

  1. Groß genug, um Code-Basis: In jedem nicht trivial Projekt werden Sie Funktionen, die einen wirklich hohen CC-Wert haben. So hoch, dass es nicht, wenn in einem Ihrer Beispiele egal, würde die CC sein 2 oder 3. Eine Funktion mit einem CC von sagen wir mal über 300 ist definitiv etwas zu analysieren. Es spielt keine Rolle, ob die CC 301 oder 302 ist.
  2. Vergessen Sie nicht, den Kopf zu benutzen. Es gibt Methoden, die viele Entscheidungspunkte benötigt. Oft können sie irgendwie weniger haben werden Refactoring, aber manchmal können sie nicht. Nicht mit der Regel gehen wie „Umgestalten alle Methoden mit einem CC> xy“. Werfen Sie einen Blick auf sie und verwenden Sie Ihr Gehirn zu entscheiden, was zu tun ist.

Ich mag die Idee eines wöchentlichen Analyse. Bei der Qualitätskontrolle, ist die Trendanalyse ein sehr effektives Werkzeug für Probleme beim Erstellen indentifying. Das ist so viel besser, als warten, bis sie so groß werden, dass sie offensichtlich wird (siehe SPC für einige weitere Details).

CC ist kein Allheilmittel für die Qualitätsbeurteilung. Offensichtlich eine wiederholte Aussage ist nicht „besser“ als eine Schleife, auch wenn eine Schleife eine größere CC hat. Der Grund für die Schleife einen größeren CC hat, ist, dass manchmal ist es vielleicht noch ausgeführt werden und manchmal ist es vielleicht nicht, die zu zwei verschiedenen „Fälle“ führt, die beide getestet werden soll. In Ihrem Fall wird die Schleife immer dreimal ausgeführt werden, da Sie eine Konstante verwenden, aber CC ist nicht klug genug, dies zu erkennen.

Das gleiche mit dem verketteten ifs in Beispiel 2 - diese Struktur ermöglicht es Ihnen, eine statment zu haben, die ausgeführt werden, wenn nur condition1 und condition2 wahr ist. Dies ist ein Sonderfall, der nicht in dem Fall ist, mit &&. So ist die if-Kette hat ein größeres Potenzial für Sonderfälle, auch wenn Sie in Ihrem Code verwenden, dies nicht.

Das ist die Gefahr der Anwendung von jeder metric blind. Die CC-Metrik hat sicherlich eine Menge Verdienst aber wie bei jeder anderen Technik zum Code verbessern kann sie nicht aus dem Kontext geschieden ausgewertet werden. Richten Sie Ihr Management bei Casper Jone der Diskussion der Codezeilen Messung (wünschte, ich könnte einen Link für Sie finden). Er weist darauf hin, dass, wenn Codezeilen ein gutes Maß für die Produktivität ist dann Assembler-Entwickler sind die produktivsten Entwickler auf der Erde. Natürlich sind sie nicht produktiver als andere Entwickler; es braucht sie nur eine Menge mehr Code zu erreichen, was höhere Sprachen mit weniger Quellcode tun. Ich erwähne das, was ich sage, so dass Sie Ihre Manager zeigen, wie dumm es ist, blind Metriken ohne intelligente Überprüfung der Anwendung, was die Metrik, die Sie sagt.

Ich würde vorschlagen, dass, wenn sie es nicht sind, dass Ihr Management die CC als Möglichkeit zu nutzen Spotting Potential Hot Spots im Code wäre klug, die weiter überprüft werden sollte. für das Ziel der unteren CC ohne Bezug auf Code Wartbarkeit oder andere Maßnahmen eine gute Codierung blindlings Ziel ist einfach dumm.

Zyklomatische Komplexität ist analog zur Temperatur. Sie sind beide Messungen, und in den meisten Fällen bedeutungslos ohne Kontext. Wenn ich sagte, draußen war die Temperatur 72 Grad das bedeutet nicht viel; aber wenn ich die Tatsache, fügte hinzu, dass ich bei Nordpol war die Zahl 72 wird signifikant. Wenn mir jemand gesagt, ein Verfahren hat eine zyklomatische Komplexität von 10, kann ich nicht feststellen, ob das ohne seinen Kontext gut oder schlecht ist.

Wenn ich eine bestehende Anwendung Code-Review, finde ich zyklomatische Komplexität eine nützliche „Ausgangspunkt“ Metrik. Das erste, was ich prüfen sind Methoden mit einem CC> 10. Diese „> 10“ Methoden sind nicht unbedingt schlecht. Sie bieten mir nur einen Ausgangspunkt für den Code zu überprüfen.

Allgemeine Regeln, wenn eine CC-Nummer unter Berücksichtigung:

  • Die Beziehung zwischen CC # und # Tests sollte CC # sein <= #tests
  • Umgestalten für CC # nur dann, wenn es erhöht Wartbarkeit
  • CC über 10 zeigt oft ein oder mehr -Code Smells

[Off Topic] Wenn Sie die Lesbarkeit über gute Note in den Metriken begünstigen (War es J.Spolsky, die sagte, „was gemessen ist, ist zu erhalten getan?“ - was bedeutet, dass Metriken missbraucht werden häufiger als nicht nehme ich an), ist es besser oft einen gut namens boolean verwenden, um Ihre komplexe bedingte Anweisung zu ersetzen.

dann 

if (condition1 && condition2 && condition3)
    Console.WriteLine("wibble");

werden 

bool/boolean theWeatherIsFine =  condition1 && condition2 && condition3;

if (theWeatherIsFine)
    Console.WriteLine("wibble");

Ich bin kein Experte auf diesem Thema, aber ich dachte, ich würde meine zwei Cent geben. Und vielleicht ist das alles wert ist.

zyklomatische Komplexität scheint zu finden, möglicherweise nur eine bestimmte automatisierte Verknüpfung zu sein (aber nicht unbedingt) problematischen Code-Schnipsel. Aber ist nicht das eigentliche Problem eines Tests gelöst werden? Wie viele Testfälle benötigt der Code? Wenn CC ist höher, aber Anzahl von Testfällen ist die gleiche und Code ist sauberer, keine Sorge über CC.

1.) Es gibt keinen Entscheidungspunkt gibt. Es gibt ein und nur einen Weg durch das Programm dort nur ein mögliches Ergebnis mit einem der beiden Versionen. Die erste prägnante und besser, zyklomatische Komplexität verdammt werden.

1 Testfall für beide

2). In beiden Fällen müssen Sie entweder schreiben "wibble" oder nicht.

2 Testfälle für beide

3.) Zuerst ein in nichts führen könnte, „ein“ oder „ein“ und „eins und zwei“. 3 Pfade. 2. Man könnte in nichts führen, eine der beiden oder beide. 4 Wege.

3 Testfälle für die ersten 4 Testfälle für das zweite

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top