Diskussion:McCabe-Metrik

Letzter Kommentar: vor 3 Jahren von 17387349L8764 in Abschnitt Code-Beispiel unter "Kritik"

Verständnis

Bearbeiten

Bevor erklärt wird, was hinter der "Software-Metrik von McCabe" steckt, muss erst einmal erklärt werden, was man sich unter "Software-Metrik von McCabe" überhaupt vorzustellen hat.

dass ab einer bestimmten Komplexität das Modul für den Menschen nicht mehr begreifbar ist.

Was für eine Modul? -- Kerbel 08:55, 27. Jul 2005 (CEST)

Das Software-Modul aus dem einleitenden Satz. --jpp ?! 13:24, 26. Aug 2005 (CEST)
Ein Beispiel (mit Illustration, d.h. Block- oder Flussdiagramm des Beispielmoduls) wäre nicht schlecht. — Daniel FR °∪° 12:18, 26. Aug 2005 (CEST)
Hallo, ist das hier erledigt? Ich würde auf folgenden Artikel aus 2016 verweisen, der diese Meta-Frage gut beantwortet: Zitat aus dem Artikel (ich belasse es in Englisch): "McCabe’s offering solves a different problem than a simple “lines of code” metric would. It lets managers tell senior directors that there’s a metrics program in place with plenty of industrial evidence about its effiacy. And, given the industrial–academic divide, no one in the company has the knowledge to argue with the management’s decision. This suggests that industry looks for metrics that can be communicated between the different management levels and across the levels of the development stakeholders. CC fits this bill."[1]
Ich denke deshalb Diskussion erledigt, wenn es im Artikel so verstanden wird.--17387349L8764 (Diskussion) 12:25, 19. Feb. 2021 (CET)Beantworten
  1. C. Ebert, J. Cain, G. Antoniol, S. Counsell, P. Laplante: Cyclomatic Complexity. In: IEEE Software. Band 33, Nr. 6, November 2016, ISSN 1937-4194, S. 27–29, doi:10.1109/MS.2016.147 (ieee.org [abgerufen am 19. Februar 2021]).

Teilgraph

Bearbeiten

Was ist ein Teilgraph? --217.86.161.131 10:18, 20. Nov. 2007 (CET)Beantworten

Siehe dazu Teilgraph. Ich habe jetzt auch einen passenden Link eingebaut, damit sich die Frage zukünftig durch Draufklicken beantworten lässt. --jpp ?! 10:29, 20. Nov. 2007 (CET)Beantworten
Ist also erledigt oder?
Dieser Abschnitt kann archiviert werden. 17387349L8764 (Diskussion) 12:20, 19. Feb. 2021 (CET)

Unverständlicher letzter Satz

Bearbeiten

„Da sich die zyklomatische Komplexität nicht durch Einfügen normaler Anweisungen ändert, ist die Regel von McCabe mit ZZ(Komponente) < 10 umstritten, da somit allenfalls eine Aussage über Testaufwand (Anzahl der zu testenden unabhängigen Programmpfade) getroffen wird.“

Bei diesem Satz verstehe ich Bahnhof. Der restliche Artikel gefällt mir gut. Dieser letzte Satz wirkt etwas wie ein Fremdkörper. Was will er überhaupt sagen? Worin bezieht er sich auf das Vorherige und was ist genau das Problem? --Chiccodoro 14:22, 2. Jun. 2008 (CEST)Beantworten

Ich habe den Satz mal umformuliert, ich hoffe, dass er nun besser verständlich ist. -- Froggy 15:36, 8. Jan. 2009 (CET)Beantworten
Hallo Froggy. Ich dachte, ich hätte mich schon lange bedankt, scheint nicht so. Dann hole ich das jetzt nach: Danke! --Chiccodoro 20:29, 15. Jan. 2009 (CET)Beantworten
Ist also erledigt oder?
Dieser Abschnitt kann archiviert werden. 17387349L8764 (Diskussion) 12:25, 19. Feb. 2021 (CET)

Code-Beispiel unter "Kritik"

Bearbeiten

„Die Methode umfasst acht Kontrollflusspfade, hat entsprechend eine hohe Komplexitätszahl von 9.“

Ich hab mir das Beispiel mit den Wochentagen jetzt eine Zeit lang angesehen, aber ich komm beim besten Willen nicht auf M = 9. Meiner Berechnung nach sollte für das Beispiel M = 8 sein (für M = e-n+2). Bitte um Korrektur entweder des Artikels oder meiner Logik. :) --Fibbo 18:31, 5. Okt. 2010 (CEST)Beantworten

Habe mir das gerade auch, zusammen mit jemand drittem angeschaut, und auch wir kommen auf 8. Habs im Artikel geändert. Wenn jemand anderer Meinung ist, müsste man zur (Er-)Klärung mal den graphen visualisieren. --212.23.105.165 11:50, 29. Jan. 2011 (CET)Beantworten

Die Kritik ist m.E. für dieses Codebeispiel unberechtigt. Natürlich wird das Beispiel von Menschen sofort durchschaut, aber es birgt auch Gefahren: nämlich dass irgendjemand in eine einzelne Case-Anweisung einen Seiteneffekt einbaut. Zurecht hat die folgende Umstrukturierung eine niedrigere Komplexität, weil man keine Seiteneffekte für einzelne Wochentage einbauen kann:

string[] tage = new string[] {"(unbekannter Wochentag)", "Montag", "Dienstag", "Mittwoch", "Donnerstag", "Freitag", "Samstag", "Sonntag"};
const String wochentagsName(const int nummer) {
  if ((nummer > 0) && (nummer < 8))
  {
    return tage[nummer];
  }
  return tage[0];
}

--80.153.118.57 10:21, 25. Mai 2011 (CEST)Beantworten

Hallo, es gibt durchaus berechtigte Kritik an Komplexitätsmaßen, aber hier gebe ich dir Recht: Das hier als "Kritik" angegbene Beispiel ist ungeeignet, da es tatsächlich eine vollkommen unnötig hohe Komplexität beinhaltet. Die Metrik erfasst hier also den schlechten Stil des Codes durchaus korrekt. Schönen Gruß --DownAnUp 15:10, 28. Jan. 2012 (CET)Beantworten

Ich halte die Auflösung eines Switch-Statements durch eine Liste für den falschen Ansatz. Es ist doch so, dass jeder case einen Key enthält, bei dem ein entsprechender Wert zurückgegeben wird. Diese Werte müssen nicht fortlaufend sein. Demnach wäre ein Dictionary eher angebracht. Und für den Ausnahmefall bekommt man eine Exception oder man prüft vorher, ob der Key im Dictionary enthalten ist. --5.158.162.136 12:41, 22. Jul. 2019 (CEST)Beantworten

Ich hielte es für sinnvoll, wenn der Artikel auch für das zweite Beispiel die Komplexitätszahl angeben würde - bisher steht dort lediglich, daß sie niedriger als im ersten Beispiel ist. Nach der Regel "Anzahl der binären Verzweigungen plus Eins" komme ich auf M=2. Falls das so korrekt ist, könnte jemand diesen Wert in den Artikel schreiben.--95.114.86.12 14:53, 8. Dez. 2019 (CET)Beantworten

Hallo, als Kommentar: Auf der Englischen Seite befindet sich keine Kritik-Sektion. Das Beispiel scheint mir etwas zu stark "Finger auf die Wunde", denn die Bedeutung der Metrik ist vermutlich auf anderer Ebene zu suchen, siehe Artikel von 2016: CC hat Jahrzehnte überstanden und dient speziell zur Interkommunikation Manager-Manager, Manager-Dev. Des Weiteren wird die Berechnung in anderen neueren Ansätzen wie z.B. der Cognitive Complexity (siehe Whitepaper von SonarQube) neu hinterfragt. In eigener Sache: Die ComC und die CogC Metrik scheinen sich im Trend gleichwertig zu verhalten (kein wissenschaftlich-empirischen Beleg dafür), d.h. man kann hier wieder auf die Aussage im 2016 Artikel referenzieren: CC ist gut für industrielle, praxis-nahe Situationen als Medium der Code-Situations-Kommunikation, wenn man es so bezeichnen kann. Zur Diskussion ob 10, 50 oder 100 siehe auch diese Frage in Stack Overflow, wo ich denke es gibt keine einfache Antwort, jedoch der Grundtenor das >100 mindestens QA/QM und Reviews unterzogen werden sollte. Studien dazu wären interessant. --17387349L8764 (Diskussion) 12:36, 19. Feb. 2021 (CET)Beantworten

Strukturierte Programmierung

Bearbeiten

Ich finde es sehr löblich, wenn sich Programmierer mit der Komplexität ihrer Programme auseinandersetzen. McCabe hat aber nicht nur eine geeignete Metrik definiert (vergleiche seine Veröffentlichung "A Complexity Measure"), er hat im Abschnitt VI seines Papiers explizit auf die nicht-strukturierte Programmierung hingewiesen. Ein strukturiertes Programm hat nach Kasaraju exakt einen Ausstiegsknoten (das ist Wissen aus der Mitte der 1970er Jahre). Solche Programme können immer durch Modularisierung oder Unterprogrammbildung so vereinfacht werden, dass die Komplexität der äußersten Programmstruktur eins ist (es gibt dann keine Kontrollstrukturen mehr - also Schleifen oder Verzeigungen - im Ablaufdiagramm, nur noch einen Aufruf eines Unterprogramms).

Wenn die Komplexität von Programmen untersucht werden soll, macht es keinen Sinn Spaghetti-Code zu untersuchen, der über vielfältige Ausstiegsknoten verfügt und daher unstrukturiert ist. Insofern sind beide Programmbeispiele nicht besonders gut geeignet, eine McCabe-Metrik zu veranschaulichen. Die Programmiersprache C benutzt in der Switch-Anweisung keine Begrenzer (delimiter) und ist unter anderem daher hochgradig unstrukturiert und kann nicht mit einer strukturierten Metasprache (wie der EBNF) beschrieben werden. Eine Mehrfachverzweigung in einer strukturierten Programmiersprache (wie zum Beispiel Pascal) benutzt im Quelltext solche obligatorischen Begrenzer, hat daher keine Nebeneffekte und somit auch eine erheblich geringere Komplexität und Störanfälligkeit.

Strukturierte Programmiersprachen erlauben nur eine Rücksprunganweisung (meist implizit am Ende eines Unterprogramms oder explizit durch eine Return-Anweisung), die logischerweise kategorisch die letzte Anweisung eines Unterprogramms ist. Beide Programmierbeispiele enthalten mehrere Rücksprunganweisungen und sind für die objektiv vergleichbare Analyse der Komplexität oder die Bestimmung einer Metrik daher denkbar schlecht geeignet.

Ich schlage vor, Programmierbeispiele in einer besser strukturierten Programmiersprache oder Beispiele in Form von Ablaufdiagrammen beziehungsweise von Nassi-Shneiderman-Diagrammen zu zeigen. Was spricht dagegen? --Bautsch (Diskussion) 19:25, 3. Jun. 2012 (CEST)Beantworten

Dagegen spricht mMn folgendes:
  • Erstens sind die "besser strukturierten" Programmiersprachen (welche?) wenig gebräuchlich - d.h. ein Großteil der Leser werden den Programmcode nur schwer verstehen.
  • Zweitens gehts bei der McCabe Metrik nicht um "besser strukturierte" Programmiersprachen, sondern um die Komplexität beliebiger Sprachen.
Ich würde das Beispiel aber dennoch in eines ohne switch, aber mit verschachtelten ifs umbauen, da sonst der Eindruck entstehen würde, hohe Komplexität könnte nur mit grossen switch-Statements erreicht werden. Gerne auch mit einem Nassi-Shneiderman Diagramm, besser noch mit einem Programmablaufplan.
Wichtig wäre aber, dass es zu dem Beispiel auch eine Lösung mit geringerer Komplexität gibt - bei ifs durch Subroutinen modelliert. --Sebastian.Dietrich 09:18, 4. Jun. 2012 (CEST)Beantworten

Umstritten

Bearbeiten

Allgemeine Frage zu "Interpretation der Metrik": Die Aussage ist "über 10 wird es zu schwer..." - nicht mehr und nicht weniger? Aus "über 10 ist es schwer" folgt nicht zwangsweise, dass es unter 11 in Ordnung sein muss. Sicher, dass genau das diskutiert wird? Stimmt die Grundaussage nicht? (nicht signierter Beitrag von 31.19.226.215 (Diskussion) 10:16, 2. Jul 2015 (CEST))

Hallo, schwierig. Siehe auch hier: https://stackoverflow.com/questions/745857/do-you-find-cyclomatic-complexity-a-useful-measure - grob: alles >50 sollte reviewed werden, wenn man nach "Best practice" geht. In diesem guten Artikel von 2016 wird CC grundlegend als positiv gesehen, speziell als Mittel der Kommunikation "Lage" bzw. "Situation" zwischen verschiedenen Personen (Manager-Manager, Manager-Dev) etc. Ich denke der Kommentar hier ist erledigt und sollte wenn dann grundlegend erforscht werden (empirisch), wie CC sich in verschiedenen Software (Sprachen, Projekte z.B. Embedded, Umfang, Targets, etc.) auswirkt. Gruss--17387349L8764 (Diskussion) 12:18, 19. Feb. 2021 (CET)Beantworten

Berechnung der Komplexität mit Hilfe von Knoten und Kanten

Bearbeiten

Ich würde gerne eine Diskussion anstoßen bzgl. der zur Zeit im Artikel verwendeten Formel für die Berechnung der zyklomatischen Komplexität, (also hier: M = e - n + 2p).

Meiner Meinung nach ist diese wie sie hier im Artikel verwendet wird, schlicht und ergreifend falsch.

M = e - n + 2p funktioniert nur dann, wenn davon ausgegangen werden kann, dass die Zusammenhangskomponenten des Kontrollflussgraphen EINEN Anfangsknoten und EINEN Endknoten hat. [McCabe geht in seinem Paper davon aus.] Das wird im Artikel nicht erwähnt. Die Formulierung, dass die Anzahl der Zusammenhangskomponenten gleich der Anzahl der Sprünge aus dem Programm heraus entspricht (also z.B. return-Anweisungen), ist somit eindeutig missverständlich, da in einem Programm (oder Prozedur) üblicherweise mehrere return-Anweisungen verwendet werden (und nur EIN Anfangsknoten). Mit der Formel M = e - n + 2p erhält man somit ein falsches Ergebnis, da es nur EINEN Anfangsknoten, aber MEHRERE Endknoten im Graphen gibt, wohingegen die Anzahl der Zusammenhangskomponenten gleich 1 bleibt. (Man würde annehmen, dass p gleich der Anzahl der return-Anweisungen ist und diese mal zwei nehmen.)

[Auch nachzulesen auf der englischen Wikipedia-Seite, zur Zeit unter der Fußnote a. (Here "structured" means in particular "with a single exit (return statement) per function").]

Mein Vorschlag:

1) Die Formel M = e - n + p + 1 verwenden und dabei erwähnen, dass p die Anzahl der Sprünge aus dem Programm heraus ist, wobei es nur einen Anfangsknoten im Kontrollflussgraphen gibt. Damit umgeht man den Begriff der Zusammenhangskomponente eines Graphen.

ODER

2) Die Formel M = e - n + 2p beibehalten, aber erwähnen, dass die Zusammenhangskomponenten des Graphen nur einen Anfangsknoten und einen Endknoten besitzen dürfen. Die Berechnung für ein Programm mit mehreren Endpunkten, ist dann nicht ohne weiteres möglich.

ODER

3) (So haben es Ludewig und Lichter in Software Engineering - Grundlagen, Menschen, Prozesse und Techniken. dpunkt.verlag. 3. Auflage. Seite 315 gemacht.) Die Formel M = e - n + p benutzen, wobei p hier die Anzahl der Außenverbindungen ist. Außenverbindungen sind Ein- und Ausgangsknoten. Hier hätte man den Vorteil, dass der Kontrollflussgraph mehrere Anfangsknoten haben könnte. (Der 1. Vorschlag ist also ein Spezialfall von diesem hier.)

Für eine Varianten muss man sich entscheiden, aber bitte nicht mehrere vermischen, da sonst das Ergebnis falsch berechnet werden könnte.

Viele Grüße (nicht signierter Beitrag von 88.78.217.167 (Diskussion) 11:24, 5. Mär. 2016 (CET))Beantworten

linear unabhängig?

Bearbeiten

Was bedeutet "linear unabhängig" für Pfade auf einem Graphen? Wohin kann man dafür verlinken? In Adjazenzmatrix wird auf Lineare Algebra verlinkt, aber "linear unabhängig" kommt nicht vor. --Rainald62 (Diskussion) 11:54, 27. Apr. 2016 (CEST)Beantworten

Siehe Lineare Unabhängigkeit. --Rôtkæppchen₆₈ 17:00, 7. Okt. 2016 (CEST)Beantworten
Hast offenbar die Frage nicht verstanden. --Rainald62 (Diskussion) 00:06, 9. Okt. 2016 (CEST)Beantworten

Verständlichkeit

Bearbeiten

Lieber Nutzer Meillo !

Bevor hier ein Edit-War ausbricht, möchte ich hier auf der Diskussionsseite meine Meinung kundtun:

  • Mag sein, dass der schlechte Stil, zwei unübersichtliche und die Komplexität steigernde return-Anweisungen in einer Funktion zu verwenden, bei Programmierern verbreitet ist.
  • Mag auch sein, dass ein gelernter-C-Programmierer seine Programmierweise besser verständlich findet.
  • Ich stimme zu, dass die Zeichenkettenunterstüzung der Programmiersprache C sehr schlecht ist; ohne erweiterte Bibliotheken müssen "magische" Feldgrößen bei einer Deklaration aber angegeben werden. Um sie unmagischer zu machen, könnte dem Code ein entsprechender Textkommentar hinzugefügt werden.

Wir dürfen nicht voraussetzen, dass alle interessierten Wikipedia-Leser das alles wissen, verstehen und einordnen können. Wäre es also nicht viel besser, den entsprechenden Code zum Beispiel in der Programmiersprache Java darzustellen, womit die Thematik ja auch verdeutlicht werden kann ? --Bautsch 09:59, 12. Mai 2017 (CEST)Beantworten

@Bautsch: Ich würde es in einer einfacheren Programmiersprache wie z. B. Java gut finden. --Trustable (Diskussion) 10:23, 12. Mai 2017 (CEST)Beantworten
Wie zum Beispiel welche ? --Bautsch 10:25, 12. Mai 2017 (CEST)Beantworten
Wenn ich mich noch richtig erinnere (ist sehr lange her), wird in C eine Zeichenkette mit der Anweisung
name = char[24];
deklariert. Sorry für die Verwirrung, falls ich diese gestiftet haben sollte. --Bautsch 12:17, 12. Mai 2017 (CEST)Beantworten
Eigentlich wuerde man hier in C kein Umkopieren verwenden (das wuerde sowieso strcpy(3) erfordern und das Abfangen aller Fehlermoeglichkeiten), sondern Pointer (die man auch mit = zuweisen kann). Darum kein Array sondern einen Pointer fuer die Ergebnisvariable ... aber das ist alles viel zu kompliziert. Also entweder eine andere Programmiersprache nehmen, oder in Pseudocode wechseln, oder eben zwei returns. Ich fand die letzte Option am einfachsten verstaendlich und am wenigsten invasiv. Darum habe ich sie gewaehlt. --Meillo (Diskussion) 13:25, 12. Mai 2017 (CEST)Beantworten
Hallo, ich will auch keinen Edit-War. So war das nicht gedacht. Ich wusste nicht recht, wie ich die Sache angehen sollte. Ich habe den Code bisher als Pseudo-Code verstanden, irgendwas zwischen C und Java. Eigentlich ist mir das egal, wichtig ist mir, dass das Beispiel fuer Nichtprogrammierer verstaendlich ist und dass man den Unterschied zwischen Beispiel 1 und 2 erkennen kann. Alles andere ist fuer mich dagegen nebensaechlich. Okay, wichtig ist mir schon auch, dass wir keinen schlechten Stil (Magic Numbers) propagieren, weil das sonst auf die Informatik zurueck faellt. Dann lieber den Code pseudomaessiger halten, weil es hier ja nur um den Vergleich der zwei Umsetzung und in erster Linie um deren Unterschied fuer diese Metrik geht. --Meillo (Diskussion) 13:25, 12. Mai 2017 (CEST)Beantworten

Fehler im Quelltext??

Bearbeiten

Ich will ja nicht unken, aber hätte der Montag in dem Arrays nicht den Index Wert 0? Wenn ihr mit "if ((nummer >= 1) && (nummer <= sizeof (tage)))" das Array absichert hättet ihr dann nicht echt Schwierigkeiten auf den Montag zu kommen? Ich wäre auch nicht mal verwundert der Compiler in beiden fällen den gleichen Hex Code baut.... (nicht signierter Beitrag von 62.96.90.172 (Diskussion) 13:50, 2. Mär. 2018 (CET))Beantworten

Ich sehe da aktuell keinen Fehler (mehr?). Der Zugriff auf das Array erfolgt durch tage[nummer - 1], für nummer==1 wird also "Montag" zurückgeliefert.--95.114.86.12 14:56, 8. Dez. 2019 (CET)Beantworten