Il numero medio di bug per località è lo stesso per diversi linguaggi di programmazione? [chiuso]

Mi è stato detto che il numero medio di bug / difetti per riga di codice è "costante" per diversi linguaggi di programmazione. 10 KLOC di Ruby avrebbero lo stesso numero di bug di 10 KLOC di c ++. L'argomento è di solito usato per promuovere l'uso di linguaggi espressivi (pensa a pitone / ruby ​​su c ++ / assembly) poiché il numero di righe per descrivere la stessa funzionalità sarebbe inferiore.

Qualcuno sa da dove viene questa affermazione? Le lingue di livello superiore portano a un minor numero di bug?

Contrariamente all'intuizione, il numero di errori per 1000 righe sembra essere relativamente costante, senza controllo della lingua specifica in questione. Steve McConnell , autore di Code Complete e Software Stimation: Demystifying the Black Art analizza in dettaglio quest'area.

Non ho le mie copie prontamente a portata di mano - sono seduti sulla mia libreria al lavoro - ma un rapido Google ha trovato una citazione pertinente:

Media del settore: "circa 15-50 errori per 1000 righe di codice consegnato".
(Steve) afferma inoltre che questo è solitamente rappresentativo del codice che ha un certo livello di programmazione strutturata dietro di esso, ma probabilmente include un mix di tecniche di codifica.

Citato da Code Complete , trovato qui: http://mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

Se la memoria funziona correttamente, Steve entra in una discussione approfondita di ciò, dimostrando che le cifre sono costanti tra le lingue (C, C ++, Java, Assembly e così via) e nonostante le difficoltà (come la definizione del significato di "linea di codice").

Soprattutto ha molte citazioni per le sue fonti - non offre opinioni prive di fondamento, ma ha i riferimenti per sostenerle.

Sembra ridursi a questo: il numero medio di difetti per kloc sembra essere più una proprietà del fatto che gli sviluppatori sono umani fallibili che dei vantaggi o svantaggi peculiari di un particolare linguaggio o piattaforma.

(A parte: se non hai già il codice completo, vai a comprarti una copia e leggilo attentamente - vale la pena l'investimento.)

Aggiornamento : c'è un altro fattore in gioco con alcune delle risposte qui: le statistiche su larga scala sono utili per fare previsioni generali ma non specifiche. Considera, le tabelle sulla mortalità della popolazione possono prevedere quante persone saranno uccise negli incidenti stradali quest'anno ma non possono dirti quali persone moriranno. Allo stesso modo, le statistiche del settore che mostrano un numero relativamente costante di difetti per kloc non possono essere utilizzate per prevedere quanto bene - o quanto male - un determinato sviluppatore eseguirà o cosa accadrà in un determinato progetto.

L'affermazione è - nella migliore delle ipotesi - ingenua.

SLOC non è esattamente una metrica affidabile per qualcosa di utile, tranne forse confrontando la dimensione di due o più progetti. Inoltre ci sono due tipi distinti di SLOC, LOC fisico e LOC logico, e quelli potrebbero differire in modo significativo. Considera questo esempio, da Wikipedia :

for (i = 0; i < 100; i += 1) printf("hello"); 

Qui abbiamo un LOC fisico, ma due logici ( fore printfistruzioni). Ma potremmo ovviamente scrivere l'esempio come:

for (i = 0; i < 100; i += 1) 
  printf("hello"); 

Il che ci darebbe due LOC fisici e due LOC logici. Penso che sia chiaro che qualsiasi misura di "bug per loc" che dipenderebbe da LOC fisici sarebbe contaminata dallo stile di programmazione, quindi la nostra misurazione sarebbe in gran parte inutile.

Se, d'altra parte, andassimo con LOC logici, allora la nostra misurazione dipenderebbe fortemente dalle idiosincrasie sintattiche della lingua. Sebbene la metrica risultante possa essere un po 'utile quando si confrontano progetti scritti nella stessa lingua, sarebbe abbastanza inutile per progetti scritti in lingue diverse.

Una possibile fonte per l'affermazione sono i fallimenti, le follie e gli errori del software di Les Hatton :

Possiamo concludere che la scelta del linguaggio di programmazione è nella migliore delle ipotesi debolmente correlata all'affidabilità.

Successivamente, l'articolo menziona densità di difetto simili per C e C ++:

In uno studio recente che ha confrontato due sistemi simili di dimensioni simili (circa 50.000 linee ciascuno), uno in C e uno in C ++ progettato per oggetti, le densità di difetto risultanti sono state mostrate intorno allo stesso rispettivamente a 2,4 e 2,9 per 1000 linee.

Ciò, tuttavia, non significa che "bug per LOC" sia costante nei linguaggi di programmazione o che sarebbe significativo se lo fosse.

Questa osservazione è molto antica e proviene da una fonte molto venerabile, vale a dire Fred Brooks nel suo libro "The Mythical Man Month". Era un top manager di IBM e gestiva numerosi progetti di programmazione tra cui il sistema operativo Milions-of-line OS / 360. In effetti ha riferito che il numero di bug in un programma non è proporzionale alla lunghezza del codice, ma quadratico ! Secondo le sue ricerche, il numero di bug era proporzionale alla lunghezza del programma rispetto alla potenza 1.5. In altre parole, un programma che è dieci volte più lungo ha 30 volte più bug. E ha riferito che questo valeva per tutti i linguaggi di programmazione e livelli di linguaggi di programmazione.

Non trovo che i bug per LOC siano costanti per una determinata lingua. I bug per LOC sembrano una metrica che alcuni manager usano per determinare la qualità degli sviluppatori quando si tratta di rivedere i tempi.

Ora al di fuori di questo, alcune lingue sono più inclini a errori o difetti di altre. Di solito, ma non sempre questo è un linguaggio di livello inferiore rispetto a un linguaggio di livello superiore. Ad esempio la codifica in C contro C # (o Java.) Dico di solito perché la realtà di esso e il punto cruciale della risposta che stai cercando si riduce alla qualità dello sviluppatore e alle pratiche di codifica in atto. Ho visto ottimi sviluppatori C con una qualità del codice molto più alta e un numero di difetti inferiore rispetto agli sviluppatori Java / C # medi. Questo è un elemento che separa uno sviluppatore senior da uno junior. Non quanti LOC scrivono in un determinato intervallo di tempo, ma la qualità del codice la scrive indipendentemente dalla lingua, LOC o intervallo di tempo.

L'unica cosa che posso dare che potrebbe essere correlata è che più LOC ci sono, più è probabile che ci sia un difetto e più difetti esistano.

Bug per riga di codice

Bugs / LOC è relativo solo a un individuo. Per le aziende che implementano strumenti di tracciamento dei bug che si collegano al loro repository di codice sorgente. È possibile per un manager organizzare i problemi per sviluppatore, ordinati per problemi passati e modifiche al codice.

I bug sono relativi al tuo lavoro

Uno sviluppatore di software senior, di grande esperienza, altamente qualificato, molto intelligente e in grado di svolgere lavori indipendenti ha molte più probabilità di avere più bug registrati in un sistema di tracciamento, quindi uno sviluppatore junior con poca esperienza.

Come è possibile?

Gli sviluppatori senior sono spesso impegnati in attività di sviluppo a rischio più elevato. Refactoring del codice e costruzione di nuovi sistemi come esempio. Gli sviluppatori junior sono spesso assegnati a risolvere problemi noti che non valgono il tempo di uno sviluppatore senior.

Pertanto, per assegnazione di compiti un junior non introduce bug ma li corregge, e uno sviluppatore senior ha il rischio di introdurli, perché il vantaggio di ciò che stanno cercando di archiviare è più importante dei problemi minori che vengono sollevati completando quelli compiti.

La sintassi della lingua è importante

L'argomento secondo cui una lingua introduce meno bug, perché può ottenere di più in meno righe di codice è un mito completo. Linguaggi altamente strutturati come C ++ / C # / Java costringono lo sviluppatore a esprimere chiaramente per iscritto ciò che dovrebbe essere l'istruzione desiderata, laddove linguaggi come Python / PHP non sono molto strutturati. Tali lingue consentono espressioni scritte che non solo confondono uno sviluppatore, ma anche il parser di lingua.

Il compilatore riduce i bug

Quanti bug in Python / PHP sono arrivati ​​ai server di produzione, perché non c'era un compilatore per avvisare lo sviluppatore che qualcosa non era corretto. Quando si misurano i bug per LOC, prima o dopo che un compilatore ha elaborato il codice sorgente?

Aggiornamento 2019:

I compilatori non fanno alcuna differenza sulla natura o sul numero di bug. I bug sono puramente relativi alla persona che ha scritto il codice sorgente e i bug stessi possono essere di natura molto soggettiva.

FWIW, nella mia esperienza

1. Esistono due tipi di bug: a) in cui il programma non soddisfa le aspettative eb) in cui il programma non può soddisfare alcuna ragionevole aspettativa, poiché si blocca / si blocca / non viene compilato.

2. Indipendentemente dalla lingua, i bug di tipo (b) sono causati dalla ridondanza nella struttura di dati / classe, in cui la modifica di qualcosa in una parte della struttura di dati pone la struttura in uno stato incoerente / rotto fino a quando una o più modifiche corrispondenti vengono apportate in altre parti . Contribuire a ciò è la ridondanza del codice sorgente, in cui una modifica a una riga di codice rende il codice errato fino a quando non vengono apportate una o più modifiche in altre parti. Questi due tipi di ridondanza sono strettamente correlati, ovviamente, e poiché i programmatori non sono super-persone si distraggono, dimenticano le cose e commettono errori, mettendo così in errore.

Queste cose (di nuovo, nella mia esperienza) non sono realmente una funzione della lingua, ma dell'abilità / maturità del programmatore. I programmi che sono molto meno soggetti a bug tendono anche ad essere molto più piccoli, in termini di LOC, per un determinato set di funzionalità.

Ho visto sistemi in cui alcune persone scrivono programmi, mentre altri scrivono directory e i primi tendono a "funzionare" rispetto al secondo.

Mi aspetto che un fattore chiave negli errori di codifica si riferisca a quello che chiamo "gap semantico" tra un particolare tipo di definizione della soluzione e il codice per risolverlo - dove questi sono errori di riformulazione ravvicinati sarebbe più evidente, dove il codice è molto diverso, ci si possono aspettare molti errori. Il paradigma di alcune lingue corrisponde strettamente a determinati domini problematici: i fogli di calcolo sono molto appropriati per i calcoli aziendali di tutti i giorni, con il risultato che sia il pochissimo "codice" che il "codice" sono molto vicini al dominio problematico. Il codice previsto è sia molto conciso (poco KLOC) sia pochi errori. Al contrario, l'utilizzo dell'assemblatore richiederebbe molti KLOC ed è probabile che produca un numero immenso di errori.

Invece di parlare di righe di codice - che sono davvero una metrica inutile - vorrei affrontare questa parte della tua domanda:

Le lingue di livello superiore portano a un minor numero di bug?

Questo è diverso dai bug / LOC, perché le lingue di livello superiore fanno di più con meno codice. L'implementazione di alcuni requisiti di funzionalità potrebbe richiedere 500 righe di LISP contro 15000 righe di assembly x86.

Quindi, anche se i bug / LOC sono costanti tra tutte le lingue, la lingua di livello superiore produrrà ancora meno bug.