Diskussion:Halstead-Metrik

aus Wikipedia, der freien Enzyklopädie

Eine von mir an einem Nachmittag erstellte Implementierung der Halstead und McCabe Metriken hat laut Halstead zB eine Implementierungszeit von 89 Stunden, das ist von den tatsächlich verwendeten 5 Stunden doch beträchtlich weit entfernt. Eine Formulierung wie und überraschenderweise meist ein wirklich gutes Maß für die Komplexität hätte ich daher gerne nachvollziehbar belegt. Eine Betrachtung der Linux-Kernel Sourcen wäre dafür zB hilfreich und aussagekräftig.

Zudem halte ich es für sehr überlegenswert den Artikel vollständig zu löschen. Der Artikel belegt in keiner Weise die Relevanz der Metirc und dient meines Erachtens in wesentlichem Maße der Unterbringung zweier Links auf eine Firmenseite. --87.79.105.54 13:18, 26. Jun. 2012 (CEST)

Ich habe gerade mal den im Artikel verlinkten Algorithmus zur Berechnung der Wartbarkeit, der ja wesentlich auf Halstead beruht, auf den aktuellen Linux Kernelsource angewendet. Demzufolge sollten 11.530 von 16.945 Dateien (C-SourceFiles) neu geschrieben werden. Angesichts eines solchen Ergebnisses, kann ich mir nicht vorstellen, dass die hier vorgestellten Metriken in der Praxis irgendeine Relevanz haben. --87.79.105.54 16:09, 26. Jun. 2012 (CEST)
PS: lediglich 2.496 dateien des Kernels wernde als gut wartbar gewertet - das sind knapp 15%. Ob die Kernel-Maintainer das unterschreiben würden, wage ich zu bezweifeln. --87.79.105.54 16:14, 26. Jun. 2012 (CEST)

Die Halstead Metriken stammen aus 1977, die McCabe Metrik aus 1976. Beide machen nur Aussagen zu einzelnen Funktionen. Sie für Gesamtaussagen zu heutigen Programmen anzuwenden ist zumindest sehr gewagt. Dennoch haben beide Metriken auch heute noch Gültigkeit - wenn eine der Metriken sagt, dass ein großer Teil der Funktionen/Methoden einer Software schlecht wartbar sind, dann ist das ein deutlicher Hinweis darauf, dass dem so ist (egal was die Maintainer dazu sagen). Beide Metriken werden vielerorts benutzt, um qualitativ hochwertige, wartbare Software zu erstellen. z.B. finden sie Anwendung in dem wohl besten Werkzeug für statische Code-Analyse (Sonar (Entwicklungswerkzeug)). --Sebastian.Dietrich 19:10, 26. Jun. 2012 (CEST)

Stimmt nicht so ganz - beide machen auch Aussagen auf Datei- bzw Modulebene. Wenn sie sich rein auf Funktionen beschränken würden, wäre das wohl wesentlich einfacher. Die für Dateien gewählten Limits (4 bis 400 Zeilen) sind gerade für große Projekte wie den Linux-Kernel schlicht zu klein angesetzt. Und genau diese zu kleinen Grenzwerte sorgen dann für einen sehr schlechten MaintainabilityIndex. Dazu kommt, dass die bewertung der Kommentarzeilen mit dem Sinus in die Formel eingeht. Sprich - wenn nicht eine sehr enge Relation gesamtzeilenzahl/kommentarzeilen eingehalten wird, dann läuft auch deswegen der Index aus dem Ruder. Alles sehr schön willkürlich ...
Zu Sonar: eines der besten von prinzipbedingt fragwürdigen Tools, ist keineswegs gut. --195.14.204.57 19:50, 27. Jun. 2012 (CEST)
So wie ich die beiden Metriken verstanden habe machen sie ausschliesslich Aussagen auf Funktionsebene - bei McCabe bin ich mir dessen sicher. Die Limits (4 bis 400) sind meines Wissens nach nur in dem Artikel drinnen, sind willkürlich gewählt und haben mit den Metriken nichts zu tun.
Aber egal - beide Metriken existieren, über beide wurde viel geschrieben, beide werden in modernen Werkzeugen verwendet, keine davon gilt als überholt/abgelöst durch andere Metriken. Unter Komplexität_(Informatik)#Komplexitätsmetriken findest noch andere Metriken zur Komplexität, die meisten ähnlich alt wie die beiden.
Metrik hin oder her, egal wie ich sie messe, hohe Komplexität führt zu hohen Aufwänden, das hat jeder Informatiker schon mal erfahren. Vermeidung von Komplexität wird aber leider meist hinter andere Dinge (wie Features, Performance) gereiht - und schlussendlich zahlt man viel zuviel für viel zuwenig. Das zu verdeutlichen hilft mMn jede ernstgenommene Metrik oder Berechnung wie z.B. die Berechnung der Technischen Schuld. --Sebastian.Dietrich 20:37, 27. Jun. 2012 (CEST)

Was ist V? Gemeint ist wohl HV? --Fritz Bierbaum (Diskussion) 19:10, 31. Mär. 2013 (CEST)