Fehler, die mit Codierungsstandards vermieden werden können [geschlossen]

Ich suche nach Statistiken (oder Schätzungen), die die Behauptung stützen, dass Codierungsstandards zur Reduzierung von Fehlern beitragen. Harte Zahlen wären nett, obwohl ich nicht viel gesucht habe. Ich habe mir sogar die Fehlerverfolgung für verschiedene Open-Source-Projekte angesehen, war aber nicht sehr erfolgreich darin, das zu finden, was ich brauche. Kennt jemand da draußen einen Ort, an dem ich das finden könnte? Oder trägt einer von Ihnen zu Open-Source-Projekten bei, bei denen Fehler aufgetreten sind, die möglicherweise durch bessere Codierungsstandards vermieden wurden?

Codierungsstandards allein reduzieren Fehler nicht. Codierungsstandards als Teil eines soliden Softwareentwicklungsprozesses reduzieren Fehler.

Hier sind zwei Artikel, die die statistischen Auswirkungen eines soliden Softwareentwicklungsprozesses auf die Fehlerreduzierung untersuchen, die Sie als Ausgangspunkt verwenden können:

• Top 10-Liste zur Reduzierung von Softwarefehlern , in der Verbesserungen in der empirisch basierten Softwareentwicklung seit 1987 untersucht werden
• Eine kritische Analyse des PSP-Datenprozesses , in der Statistiken aus dem Personal Software-Prozess und die Auswirkungen von PSP auf häufige Ursachen von Softwarefehlern untersucht werden

Codierung von "Standards" ... Es gibt viele Entwicklungsbereiche, die standardisiert werden können. Sprechen wir über Codierungskonventionen wie Namensstandards usw.? Oder sprechen wir über etwas Tieferes wie TDD / BDD, CI usw.?

Ich kann Ihnen sagen, dass die Einhaltung einer "Test-First" -Methode, bei der CI das Bestehen von Tests und eine gute Codeabdeckung erzwingt, die Anzahl der vom Client gefundenen Fehler verringert. Automatisierte Tests sowohl durch den Entwickler als auch durch die Qualitätssicherung sind ebenfalls eine relativ "billige" Methode, um Fehler zu finden, da sie im Allgemeinen sehr kurze Feedbackzeiten haben. Sie können feststellen, dass Sie nicht das geschrieben haben, was Sie zu schreiben glaubten, indem Sie Unit-Tests im Wert von etwa 45 Sekunden durchgeführt haben. Ein paar Stunden Integrationstests werden Orte finden, an denen das Zusammenstecken nicht wie geplant verlief, und durchgängige und automatisierte UI-Tests können Funktionsfehler in der Software auf sehr hohem Niveau schnell erkennen.

Sie verhindern auch eine Regression. Du hast einen Fehler gefunden. Sie schreiben einen Test, der beweist, dass das Verhalten nicht mehr auftritt, Sie codieren, bis der Test bestanden ist, und jetzt haben Sie einen Test, der von diesem Punkt an sicherstellt, dass der Fehler nie wieder ein Problem darstellt. Dies ist meiner Erfahrung nach eine Hauptquelle für neue Fehler. Wenn Sie eine Sache reparieren, wird etwas anderes kaputt gemacht, und Ihre Entwicklertests des Fixes decken möglicherweise nicht die andere Situation ab, die jetzt kaputt ist. Dinge zu zerbrechen, die früher funktionierten, ist für Ihre Kunden eine RIESIGE rote Fahne.

Schließlich bietet Ihnen diese automatisierte Teststruktur, die Sie als Teil dieser Methodik erstellen, sehr einfach eine Umgebung, in der Sie buchstäblich jederzeit einen neuen Build der Software veröffentlichen können. "Hey, dieser Fehler, den du gerade behoben hast, hat einige echte Kopfschmerzen verursacht. Wann wirst du ihn in einer neuen Version fertig haben?" Klicken Sie auf "Oh, in ungefähr 5 Minuten, wenn der Build-Server die Veröffentlichung auf der Download-Seite abgeschlossen hat".

In Bezug auf grundlegende Codierungskonventionen wie das Standardisieren von Variablennamen usw. habe ich festgestellt, dass das meiste davon weniger nützlich und irritierender ist. Das sind die Standards, die "wunderbar sind, weil so viele zur Auswahl stehen". Was Sie als Unterschied zwischen einer PascalCased- und einer camelCased-Kennung wahrnehmen, entspricht möglicherweise nicht dem, was andere denken. Führende Unterstriche, Namenslängenbeschränkungen (oder Anforderungen, die Methoden- / Feldnamen an eine Geschichte erzählen); Abgesehen von Konventionen, die vom Compiler erzwungen werden oder die häufig in sprachspezifischem Bibliothekscode vorkommen, kann die moderne IDE Ihnen alles sagen, was Sie über eine Variable oder Funktion wissen müssen, einschließlich der Frage, ob Sie versuchen sollten, sie in einer bestimmten zu verwenden oder nicht Umstand. Darüber hinaus führt das Ausführen einer Codekonventionsprüfung häufig zu Problemen mit Code, den Sie nicht oder nicht verwenden können. Sie möchten keine Änderungen vornehmen, z. B. eine Bibliothek eines Drittanbieters, die andere Standards verwendet hat, oder Interop-Code, der möglicherweise den Win API-Namensstandards anstelle der Standards Ihrer Muttersprache entspricht. Am Ende fügen Sie Ihrem Code Cruft hinzu, um Ihr Tool anzuweisen, die Cruft in Ihrem Code zu ignorieren.

Jede SQL-Injection-Schwachstelle ist ein Fehler, der mit einem Codierungsstandard hätte verhindert werden können. Statistiken zu SQL-Injection-Schwachstellen sind verfügbar, AFAIK.

Jede Sicherheitsanfälligkeit durch Pufferüberlauf hätte mit einem Codierungsstandard verhindert werden können. Statistiken dazu sind wahrscheinlich auch verfügbar.