Bug che possono essere evitati con gli standard di codifica [chiuso]

Sto cercando statistiche (o stime) che sostengano l'affermazione secondo cui gli standard di codifica aiutano a ridurre i bug. I numeri difficili sarebbero carini, anche se non ho avuto molto look a trovarne. Ho anche esaminato il bug tracking per vari progetti open source, ma non ho avuto molto successo nel trovare ciò di cui ho bisogno. Qualcuno là fuori conosce qualche posto in cui potrei essere in grado di trovarlo? O qualcuno di voi contribuisce a progetti open source che hanno avuto bug che potrebbero essere stati evitati con standard di codifica migliori?

Gli standard di codifica da soli non riducono i bug. Gli standard di codifica come parte di un solido processo di sviluppo software riducono i bug.

Ecco due articoli che studiano l'impatto statistico del processo di ingegneria del software audio sulla riduzione dei difetti che è possibile utilizzare come punto di partenza:

• Top 10 della riduzione dei difetti del software , che rileva i miglioramenti nell'ingegneria del software basata empiricamente dal 1987
• Un'analisi critica del processo dati PSP , che studia le statistiche raccolte dal processo del software personale e l'impatto della PSP sulle cause comuni di errori del software

"Standard" di codifica ... Ci sono molte aree di sviluppo che possono essere standardizzate. Stiamo parlando di convenzioni di codifica, come standard di denominazione ecc.? O stiamo parlando di qualcosa di più profondo, come TDD / BDD, CI, ecc?

Posso dirti che l'adesione a una metodologia "test-first", con CI che impone il superamento di test e una buona copertura del codice, riduce il numero di bug rilevati dal client. I test automatizzati, sia da parte dello sviluppatore che del QA, sono anche un modo relativamente "economico" di trovare bug perché generalmente hanno tempi di feedback molto brevi. Puoi sapere che non hai scritto ciò che pensavi di aver eseguito eseguendo test di unità per circa 45 secondi. Un paio d'ore di test di integrazione troveranno luoghi in cui collegare le cose non è andato come previsto, e i test UI end-to-end e automatizzati possono individuare rapidamente guasti funzionali nel software a livelli molto alti.

Inoltre impediscono la regressione. Hai trovato un bug. Scrivete un test che dimostrerà che il comportamento non si verifica più, codificate fino al superamento del test e ora avete un test che da questo punto in poi garantirà che il bug non sarà mai più un problema. Questa è, secondo la mia esperienza, una delle principali fonti di nuovi bug; risolvere una cosa interrompe qualcos'altro e il test da parte dello sviluppatore della correzione potrebbe non coprire quell'altra situazione che ora è rotta. Rompere cose che una volta funzionavano è una GRANDE bandiera rossa per i tuoi clienti.

Infine, questa struttura di test automatizzata che costruisci come parte di questa metodologia ti darà molto facilmente un ambiente in cui puoi rilasciare una nuova build del software con un preavviso letterale di un momento. "Ehi, quel bug che hai appena risolto ha causato dei veri mal di testa; quando lo avrai pronto in una nuova versione?" fai clic su "Oh, in circa 5 minuti quando il server di compilazione termina la pubblicazione nella pagina di download".

Per quanto riguarda le convenzioni di base sulla codifica, come la standardizzazione dei nomi delle variabili, ecc., Ho riscontrato che la maggior parte di esse è meno utile e più irritante. Questi sono i tipi di standard che sono "meravigliosi, perché ce ne sono così tanti tra cui scegliere". Ciò che percepisci come la differenza tra un identificatore PascalCased e CamelCased potrebbe non essere quello che qualcun altro pensa. Sottolineature principali, limiti di lunghezza dei nomi (o requisiti che i nomi di metodo / campo raccontano una storia); a parte le convenzioni applicate dal compilatore o che sono comunemente visualizzate nel codice della libreria specifico della lingua, il moderno IDE può dirti tutto ciò che devi sapere su una variabile o funzione, incluso se dovresti o non dovresti provare a usarlo in un particolare circostanza. Inoltre, l'esecuzione di un controllo della convenzione del codice restituisce spesso problemi con il codice che non è possibile o non si ' non voglio cambiare, come una libreria di terze parti che utilizzava un diverso set di standard o codice di interoperabilità che potrebbe essere conforme agli standard di denominazione API Win anziché agli standard della tua lingua madre. Si finisce per aggiungere cruft al proprio codice per indicare al proprio strumento di ignorare la cruft nel proprio codice.

Ogni vulnerabilità di SQL injection è un difetto che avrebbe potuto essere prevenuto con uno standard di codifica. Sono disponibili statistiche sulle vulnerabilità dell'iniezione SQL, AFAIK.

Ogni vulnerabilità di overflow del buffer avrebbe potuto essere prevenuta con uno standard di codifica. Probabilmente sono disponibili anche statistiche su quelli.