Das hängt auch davon ab, wer den Code geschrieben hat (Erfahrungsebene) und wie groß die Codebasis ist.
Ich würde alle Warnungen als Fehler behandeln.
Wie viele Fehler erhalten Sie, wenn Sie ein statisches Analysetool für den Code ausführen?
BEARBEITEN
Führen Sie cccc aus und überprüfen Sie die zyklische Komplexität von mccabe. Es sollte zeigen, wie komplex der Code ist.
Führen Sie andere statische Analysetools aus.
Welche Fehlerrate kann ich in einer C ++ - Codebasis erwarten, die für einen eingebetteten Prozessor (DSP) geschrieben ist, da es keine Komponententests, keine Codeüberprüfungen, keine statische Codeanalyse und das Kompilieren des Projekts etwa 1500 gibt Warnungen. Sind 5 Fehler / 100 Codezeilen eine vernünftige Schätzung?
Trotz meiner Skepsis bezüglich der Gültigkeit einer Schätzung in diesem Fall habe ich einige relevante Statistiken gefunden.
In diesem Artikel zitiert der Autor Zahlen aus einer "großen Sammlung von empirischen Studien ", veröffentlicht in Software Assessments, Benchmarks und Best Practices (Jones, 2000) . Bei SIE CMM Level 1 , das sich nach dem Level dieses Codes anhört, kann man eine Fehlerrate von 0,75 pro erwarten Funktionspunkt . Ich überlasse es Ihnen zu bestimmen, wie Funktionspunkte und LOC in Ihrem Code beziehen können - Sie benötigen wahrscheinlich ein metrics tool um diese Analyse durchzuführen.
Steve McConnell im Code Complete zitiert eine Studie von 11 Projekte wurden von demselben Team entwickelt, 5 ohne Code-Reviews, 6 mit Code-Reviews. Die Fehlerrate für den nicht überprüften Code betrug 4,5 pro 100 LOC und für den überprüften Code betrug sie 0,82. Auf dieser Grundlage scheint Ihre Schätzung in Abwesenheit anderer Informationen fair zu sein. Ich muss jedoch ein gewisses Maß an Professionalität in diesem Team annehmen (allein aufgrund der Tatsache, dass sie das Bedürfnis verspürten, die Studie durchzuführen) und dass sie zumindest die Warnungen beachtet hätten; Ihre Fehlerquote könnte viel höher sein.
Der Punkt über Warnungen ist, dass einige gutartig sind, und einige sind Fehler (d. h. werden zu unerwünschtem Verhalten der Software führen). Wenn Sie sie ignorieren unter der Annahme, dass sie alle gutartig sind, werden Sie Fehler einführen. Darüber hinaus werden einige Fehler, die sich in der Wartung befinden, wenn sich andere Bedingungen ändern, aber wenn Sie bereits eine Warnung akzeptiert haben, haben Sie keine Abwehr gegen die Einführung solcher Fehler.
Ihre Frage ist "Ist 5 Mängel / 100 Zeilen Code eine angemessene Schätzung?" Diese Frage ist extrem schwer zu beantworten und hängt stark von der Codebasis ab. Codekomplexität.
Sie haben auch in einem Kommentar erwähnt "um dem Management zu zeigen, dass es wahrscheinlich viele Fehler in der Codebasis gibt" - das ist großartig, ein großes Lob, genau richtig.
Um die figürlichen Augen des Managements zu öffnen, würde ich mindestens einen 3-Punkte-Ansatz vorschlagen:
Noch ein anderer Punkt: Ich benötige saubere Kompilierungen in meinen Gruppen und säubere auch die Lint-Ausgabe. Gewöhnlich kann dies nur durch das Schreiben von gutem Code erreicht werden, aber gelegentlich müssen die Compiler / Lint-Warnungen optimiert werden, um das Werkzeug für Dinge, die keine Probleme sind, zu beruhigen (sinnvoll einsetzen).
Aber der wichtige Punkt, den ich machen möchte, ist dies: sei sehr vorsichtig, wenn du hineingehst & amp; Fixierungscompiler & amp; Fusselwarnungen . Es ist ein bewundernswertes Ziel, aber Sie können auch unbeabsichtigt Arbeitscode brechen und / oder undefiniertes Verhalten aufdecken, das versehentlich im "kaputten" Code funktioniert hat. Ja, das passiert wirklich. Also vorsichtig gehen.
Wenn Sie bereits über eine Reihe fester Tests verfügen, können Sie feststellen, ob Sie beim Refactoring versehentlich etwas kaputt gemacht haben.
Viel Glück!
Wenn Sie die Vorteile von Komponententests, Codeüberprüfungen, statischen Analysewerkzeugen demonstrieren möchten, empfehle ich eine Pilotstudie.
Führen Sie einige Komponententests, Codeüberprüfungen und statische Analysetools für einen Teil des Codes aus. Zeige Management, wie viele Fehler du mit diesen Methoden findest. Hoffentlich sprechen die Ergebnisse für sich.
Wenn Sie eine Schätzung der Anzahl der Defekte erhalten möchten, ist die übliche Art der statistischen Schätzung die Unterabtastung der Daten. Ich würde drei mittelgroße Subroutinen nach dem Zufallsprinzip auswählen und sie sorgfältig auf Fehler überprüfen (Compiler-Warnungen eliminieren, statische Analysewerkzeuge ausführen usw.). Wenn Sie drei Fehler in insgesamt 100 zufällig ausgewählten Codezeilen finden, erscheint es vernünftig, dass eine ähnliche Dichte von Fehlern im Rest des Codes enthalten ist.
Das hier erwähnte Problem der Einführung neuer Fehler ist ein wichtiges Problem, aber Sie müssen den geänderten Code nicht erneut in den Produktionszweig eingeben, um diesen Test auszuführen. Ich würde vorschlagen, eine ganze Reihe von Komponententests durchzuführen, bevor irgendwelche Subroutinen geändert werden, und den gesamten Code aufräumen, gefolgt von sehr gründlichen Systemtests, bevor neuer Code für die Produktion freigegeben wird.
Der folgende Artikel enthält einige Zahlen, die auf realen Projekten basieren, auf die statische Analysen angewendet wurden: Ссылка
Natürlich können die Kriterien, nach denen eine Anomalie gezählt wird, die Ergebnisse dramatisch beeinflussen, was zu den großen Schwankungen in den in Tabelle 1 gezeigten Zahlen führt. In dieser Tabelle liegt die Anzahl der Anomalien pro tausend Zeilen Code für C im Bereich von 500 (!) bis etwa 10 (automatisch generiert).
Sehen Sie sich die Codequalität an. Es würde Ihnen schnell einen Hinweis auf die Menge an Problemen geben, die sich in der Quelle verbergen. Wenn die Quelle hässlich ist und lange braucht, um zu verstehen, wird es viele Fehler im Code geben.
Gut strukturierter Code mit konsistentem Stil, der einfach zu verstehen ist, wird weniger Probleme enthalten. Der Code zeigt, wie viel Mühe und Gedanken in ihn gesteckt wurden.
Ich schätze, wenn die Quelle so viele Warnungen enthält, werden sich viele Bugs im Code verstecken.