Codemetriken: zyklomatische Komplexität

Bei der Arbeit mit Codemetriken scheint eines der am wenigsten verstandenen Aspekte die zyklomatische Komplexität zu sein. Im Wesentlichen sind bei zyklomatischer Komplexität höhere Werte schlecht und niedrigere Werte gut. Sie können mithilfe der zyklomatischen Komplexität ein Gefühl dafür entwickeln, wie schwierig es sein kann, einen bestimmten Code zu testen, zu verwalten oder zu korrigieren, und wie wahrscheinlich es ist, dass der Code zu Fehlern führt. Ganz allgemein wird der Wert der zyklomatischen Komplexität berechnet, indem die Anzahl der Entscheidungen gezählt wird, die in Ihrem Quellcode getroffen werden. In diesem Artikel beginnen Sie mit einem einfachen Beispiel für zyklomatische Komplexität, um das Konzept schnell zu verstehen. Anschließend sehen Sie sich einige zusätzliche Informationen zur tatsächlichen Nutzung und vorgeschlagenen Grenzwerten an. Schließlich gibt es einen Abschnitt mit Quellen, mit denen Sie tiefer in dieses Thema vordringen können.

Beispiel

Zyklomatische Komplexität ist definiert als die Messung der „Menge der Entscheidungslogik in einer Quellcodefunktion“ NIST235. Einfach ausgedrückt: Je mehr Entscheidungen im Code getroffen werden müssen, desto komplexer ist er.

Sehen Sie sich die Anwendung in Aktion an. Erstellen Sie eine neue Konsolenanwendung, und berechnen Sie sofort Ihre Codemetriken, indem Sie Analysieren > Codemetrik für Projektmappe berechnen auswählen.

Beachten Sie, dass die zyklomatische Komplexität bei 2 liegt (der niedrigste mögliche Wert). Wenn Sie Code ohne Entscheidungen hinzufügen, können Sie sehen, dass sich die Komplexität nicht ändert:

Wenn Sie eine Entscheidung hinzufügen, steigt der Wert der zyklomatischen Komplexität um 1:

Wenn Sie die if-Anweisung in eine switch-Anweisung mit vier zu treffenden Entscheidungen ändern, steigt sie von der ursprünglichen 2 auf den Wert 6:

Sehen Sie sich eine (hypothetische) größere Codebasis an.

Beachten Sie beim Drilldown in die Products_Related-Klasse, dass die meisten Elemente den Wert 1 haben, einige jedoch eine Komplexität von 5 aufweisen. Dies mag an sich keine große Sache sein, aber angesichts der Tatsache, dass die meisten anderen Member in derselben Klasse eine 1 haben, sollten Sie sich den Inhalt dieser beiden Elemente auf jeden Fall genauer ansehen. Klicken Sie dazu mit der rechten Maustaste auf das Element, und wählen Sie im Kontextmenü Gehe zu Quellcode aus. Sehen Sie Product.set(Product) einmal genauer an:

An den vielen if-Anweisungen können Sie erkennen, warum die zyklomatische Komplexität bei 5 liegt. An diesem Punkt können Sie entscheiden, dass dies ein akzeptabler Grad an Komplexität ist, oder Sie können eine Umgestaltung durchführen, um die Komplexität zu reduzieren.

Die magische Zahl

Wie bei vielen Metriken in dieser Branche gibt es keine exakte Grenze für die zyklomatische Komplexität, die für alle Organisationen geeignet ist. In NIST235 ist jedoch angegeben, dass ein Grenzwert von 10 ein guter Ausgangspunkt ist:

„Die genaue Zahl, die als Grenzwert verwendet werden soll, bleibt jedoch umstritten. Der ursprüngliche Grenzwert von 10, der von McCabe vorgeschlagen wurde, wird durch deutliche Beweise untermauert, aber auch Grenzwerte von bis zu 15 wurden erfolgreich angewandt. Grenzwerte über 10 sollten Projekten vorbehalten bleiben, die mehrere operative Vorteile gegenüber normalen Projekten haben, z. B. erfahrenes Personal, formales Design, eine moderne Programmiersprache, strukturierte Programmierung, exemplarische Vorgehensweisen beim Code und ein umfassender Testplan. Anders ausgedrückt: Eine Organisation kann sich für eine Komplexitätsgrenze über 10 entscheiden, wenn sie absolut sicher ist, was sie tut, und bereit ist, den zusätzlichen Testaufwand in Kauf zu nehmen, der für komplexere Module erforderlich ist.“ NIST235

Zyklomatische Komplexität und Zeilenanzahl

Allein die Anzahl der Codezeilen allein zu betrachten, ist bestenfalls ein sehr oberflächlicher Indikator für die Codequalität. Der Annahme, dass mehr Codezeilen in einer Funktion die Wahrscheinlichkeit für Fehler erhöhen, liegt eine gewisse Wahrheit zugrunde. Wenn Sie jedoch die zyklomatische Komplexität mit der Anzahl der Codezeilen kombinieren, erhalten Sie ein viel klareres Bild des Fehlerpotenzials.

Dies wird auch vom Software Assurance Technology Center (SATC) der NASA beschrieben:

„Das SATC hat festgestellt, dass die effektivste Bewertung eine Kombination aus Umfang und (zyklomatischer) Komplexität ist. Module mit einer hohen Komplexität, die außerdem sehr groß sind, weisen in der Regel die geringste Zuverlässigkeit auf. Module mit geringer Größe und hoher Komplexität stellen ebenfalls ein Risiko für die Zuverlässigkeit dar, da sie in der Regel sehr wenig Code aufweisen, der nur schwierig zu ändern oder zu vereinfachen ist.“ SATC

Codeanalyse

Eine der Kategorien der Codeanalyse sind Wartbarkeitsregeln. Weitere Informationen finden Sie unter Wartbarkeitsregeln. Bei Verwendung der Legacycodeanalyse enthält der erweiterte Regelsatz für Entwurfsrichtlinien einen Wartbarkeitsbereich:

Innerhalb des Wartbarkeitsbereichs finden Sie auch eine Regel für die Komplexität:

Diese Regel gibt eine Warnung aus, wenn die zyklomatische Komplexität 25 erreicht, damit Sie übermäßige Komplexität vermeiden können. Weitere Informationen zu dieser Regel finden Sie unter CA1502.

Zusammenfassung

Unter dem Strich bedeutet eine hohe Komplexität eine höhere Wahrscheinlichkeit von Fehlern und damit mehr Zeit für die Wartung und Problembehandlung. Sehen Sie sich alle Funktionen mit hoher Komplexität genauer an, und entscheiden Sie, unabhängig davon ob sie umgestaltet werden sollten, um sie weniger komplex zu machen.

Quellen

MCCABE5

McCabe, T. und A. Watson (1994), Software Complexity (CrossTalk: The Journal of Defense Software Engineering)

NIST235

Watson, A. H. und McCabe, T. J. (1996). Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric (NIST Special Publication 500-235). Abgerufen am 14. Mai 2011 von der McCabe Software-Website: http://www.mccabe.com/pdf/mccabe-nist235r.pdf

SATC

Rosenberg, L., Hammer, T., Shaw, J. (1998). Software Metrics and Reliability (Proceedings of IEEE International Symposium on Software Reliability Engineering). Abgerufen am 14. Mai 2011 von der Website der Penn State University: https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159