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

Contrariamente all'intuizione, il numero di errori per 1000 righe sembra essere relativamente costante, senza preclusione rispetto alla lingua specifica coinvolta. Steve McConnell , autore di Code Complete e Stima del software: Demistificazione della Black Art esamina quest'area in dettaglio.

Non ho le mie copie pronte a portata di mano - sono sul mio scaffale al lavoro - ma un rapido Google ha trovato una citazione pertinente:

Industry Average: "about 15 - 50 errors per 1000 lines of delivered code."
(Steve) further says this is usually representative of code that has some level of structured programming behind it, but probably includes a mix of coding techniques.

Citato da Codice completo , trovato qui: link

Se la memoria funziona correttamente, Steve ne discute approfonditamente, dimostrando che le cifre sono costanti in tutti i linguaggi (C, C ++, Java, Assembly e così via) e nonostante le difficoltà (come definire quale "linea di codice") si intende).

Soprattutto ha molte citazioni per le sue fonti: non offre opinioni non comprovate, ma ha i riferimenti per sostenerle.

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

(a parte: se non hai già il codice completo, vai comprandoti una copia e leggila a fondo - vale la pena investire).

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. Considerate che le tabelle sulla mortalità delle popolazioni possono prevedere quante persone saranno uccise in incidenti stradali quest'anno, ma non possono dirvi 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 si esibirà o che cosa accadrà su un determinato progetto.

L'affermazione è - al meglio - ingenua.

Lo SLOC non è esattamente una metrica affidabile per qualcosa di utile, eccetto forse per confrontare le dimensioni 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 una LOC fisica, ma due logiche ( for e printf dichiarazioni). Ma potremmo ovviamente scrivere l'esempio come:

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

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

Se, d'altra parte, siamo andati con LOC logici, la nostra misurazione dipenderebbe in gran parte dalle idiosincrasie sintattiche del linguaggio. Sebbene la metrica risultante potrebbe 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 il reclamo è Problemi software - follie e errori :

We can conclude that programming language choice is at best weakly related to reliability.

In seguito, il documento menziona densità di difetti simili per C e C ++:

In a recent study comparing two similar systems of similar size, (around 50,000 lines each), one in C and one in object-designed C++, the resulting defect densities were shown to be around the same at 2.4 and 2.9 per 1000 lines respectively.

Questo, tuttavia, non significa che "bug per LOC" sia costante tra i linguaggi di programmazione, o che sarebbe significativo se lo fosse.

Questa osservazione è molto antica e proviene da una fonte molto venerabile, ovvero Fred Brooks nel suo libro "The Mythical Man Month". Era un dirigente presso IBM e gestiva molti progetti di programmazione incluso il sistema operativo milions-of-line OS / 360. Infatti ha riferito che il numero di bug in un programma non è proporzionale alla lunghezza del codice, ma quadratico ! Secondo la sua ricerca, il numero di bug era proporzionale alla lunghezza del programma alla potenza 1.5. In altre parole, un programma dieci volte più lungo ha 30 volte più bug. E ha riferito che questo riguardava tutti i linguaggi di programmazione e i livelli dei linguaggi di programmazione.

Non trovo i bug per LOC costanti per una data lingua. I bug per LOC sembrano una metrica utilizzata da alcuni manager per determinare la qualità degli sviluppatori quando si tratta di esaminare i tempi.

Al di fuori di questo, alcune lingue sono più soggette ad errori o difetti rispetto ad altre. Di solito, ma non sempre questo è un linguaggio di livello inferiore rispetto a uno superiore. Ad esempio la codifica in C rispetto a C # (o Java). Dico di solito perché la realtà e il punto cruciale della risposta che stai cercando dipende dalla qualità dello sviluppatore e dalle pratiche di codifica in atto. Ho visto degli sviluppatori C molto buoni con una qualità del codice molto più alta e conteggi di difetti più bassi rispetto agli sviluppatori medi di Java / C #. Questo è un articolo che separa uno sviluppatore senior da uno junior. Non quante LOC scrivono in un dato intervallo di tempo, ma la qualità del codice è scritta indipendentemente dalla lingua, dalla LOC o dall'intervallo di tempo.

L'unica risposta che posso dare che potrebbe riguardare è che più LOC ci sono più probabilità che ci sia un difetto e più difetti esistono.

Bug per linea di codice

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

I bug sono relativi al tuo lavoro

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

Com'è possibile?

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

Pertanto, per incarico di compiti un junior non introduce bug ma li risolve, 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 sono sollevato completando tali compiti.

La sintassi della lingua è importante

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

Il compilatore riduce i bug

Quanti bug in Python / PHP sono stati distribuiti nei server di produzione, perché non c'era alcun compilatore per avvisare lo sviluppatore che qualcosa non era corretto. Quando misuri i bug per LOC è prima o dopo che un compilatore ha elaborato il codice sorgente?

Idioti per lingua

Programmi software per persone di tutti i livelli, dal principiante all'avanzato e ci sono linguaggi di programmazione per ognuno di essi. Mentre gli sviluppatori discutono fino a quando il loro blu in faccia su quale lingua è meglio. Non c'è dubbio sul fatto che alcune lingue attraggono più idioti che altri. Alcune persone imparano Java, perché vogliono semplicemente guadagnare di più (non per nessun motivo basato sulle caratteristiche della lingua).

Quindi, se desideri selezionare un linguaggio di programmazione, con la speranza di vedere meno bug, quindi seleziona la lingua che contiene una minor quantità di idioti. Avrai meno probabilità di assumerli più tardi quando il progetto sarà cresciuto.

FWIW, nella mia esperienza

1. Esistono due tipi di bug: a) dove il programma non soddisfa le aspettative eb) dove il programma non è in grado di soddisfare ogni ragionevole aspettativa, perché si blocca / si blocca / non si compila.

2. Indipendentemente dalla lingua, i bug di tipo (b) sono causati dalla ridondanza nella struttura data / classe, dove la modifica di qualcosa in una parte della struttura dati mette la struttura in uno stato incoerente / rotto fino a quando uno o più corrispondenti le modifiche sono fatte in altre parti. Contribuire a questo è ridondanza del codice sorgente, in cui una modifica a una riga di codice rende il codice errato finché 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ì dei bug.

Queste cose (ancora nella mia esperienza) non sono in realtà una funzione della lingua, ma dell'abilità / maturità del programmatore. I programmi che sono molto meno inclini ai bug tendono anche ad essere molto più piccoli, in termini di LOC, per un dato insieme di funzionalità.

Ho visto sistemi in cui alcune persone scrivono programmi, mentre altri scrivono directory, e le prime tendono a "funzionare" rispetto a quest'ultima.

Mi aspetto che un fattore chiave negli errori di codifica si riferisca a quello che io chiamo il "divario semantico" tra un particolare tipo di definizione di soluzione e il codice per risolverlo - laddove questi sono errori di riformulazione ravvicinati sarebbe più evidente, dove il il codice è molto diverso, potrebbero esserci molti errori. Il paradigma di alcune lingue corrisponde strettamente a determinati domini problematici: i fogli di calcolo sono molto appropriati per i calcoli aziendali quotidiani, risultando in entrambi molto poco "codice" e il "codice" essendo molto vicino al dominio del problema. Il codice previsto è molto conciso (poco KLOC) e pochi errori. Viceversa l'uso di assembler 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 rispondere a questa parte della tua domanda:

Does higher-level languages lead to fewer bugs?

Questo è diverso da bug / LOC, perché i linguaggi di livello superiore fanno di più con meno codice. L'implementazione di alcuni requisiti di funzionalità potrebbe richiedere 500 linee di LISP rispetto a 15000 linee di assembly x86.

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