Quali sono i reali vantaggi dell'analisi del codice statico?

Strumenti come pc-lint o QAC possono essere utilizzati per eseguire analisi di codice statico su una base di codice.

Nella mia esperienza, l'analisi statica produce spesso un'enorme quantità di rumore, vale a dire avvertimenti su cose che non sono veri e propri bug ma che in qualche modo violano una delle regole di un determinato set di regole. Disattivare determinate regole (per sempre nel set di regole o tramite commenti speciali nel codice) può essere un processo davvero complicato.

Quali sono i reali vantaggi dell'analisi del codice statico?

Ho lavorato in un posto che utilizzava un sistema commerciale di analisi del codice statico chiamato Coverity Prevent, ed è stato davvero incredibile! È davvero sofisticato e intelligente.

Abbiamo lanciato circa 18 GB di codice C e C ++ sia open-source che proprietario e ci avrebbe tracciato attraverso i percorsi del codice e avrebbe rapidamente trovato bug sottili che richiederebbero un essere umano per rintracciarli. Era anche eccezionale nel individuare cose che di solito sarebbero Heisenbugs.

Funzionava ogni pochi giorni contro la nostra base di codice, e una bella caratteristica era che potevamo dirlo, "Questo non è davvero un bug", e lo ricorderemmo in futuro.

Il problema è che Coverity è molto costosa. Non pubblicano i costi, ma ho la sensazione che per i progetti commerciali, inizi tra centinaia di migliaia di dollari all'anno. Ma probabilmente ci ha evitato di dover assumere un sacco di sviluppatori e personale addetto al controllo qualità, quindi nel complesso il nostro management sembrava pensare che fosse un buon acquisto.

Avendo avuto questa esperienza, guardo abbastanza favorevolmente all'analisi del codice statico.

Quando inizi con una nuova lingua è bello avere un allenatore. È così che penso agli strumenti di analisi statica. Scrivo molto javascript e all'inizio ho preso alcune cattive abitudini principalmente perché stavo trasferendo alcune cose dalle lingue precedenti. Javascript è piuttosto flessibile, quindi puoi cavartela praticamente con qualsiasi cosa, ma se avessi avuto jslint che mi avvertiva su determinati schemi avrei raccolto migliori schemi di codifica fin dall'inizio invece di dover riapprendere cose in seguito.

Gli analizzatori statici sono essenzialmente revisioni di codice assistite da macchine. Indicheranno aree discutibili che potrebbero essere perse durante i test regolari.

Ad esempio, l'autore intendeva davvero fare un incarico in questo condizionale?

if (x = 1) {
    ...
}

O forse un novellino confonde il casting lessicale:

char* number = "123";
int converted = number;

Certamente gli analizzatori statici richiedono modifiche. Inoltre, controllo di revisione, wiki, tracker di bug, stampanti graziose e altri strumenti richiedono anche qualche configurazione. Più grande è il progetto, migliore è la ricompensa per il lavoro iniziale.

Dal punto di vista di un consulente, ogni strumento di analisi statica avrà un po 'di rumore ma non tutti gli analizzatori statici sono uguali. Gli strumenti di analisi statica come Coverity, Klocwork, Grammatech hanno buone tecniche di analisi che dovrebbero produrre risultati più accurati. Se ottimizzi e ottimizzi un po 'di più, in genere ottieni risultati migliori (dopo tutto, gli analizzatori statici devono essere in grado di funzionare su tutti i diversi tipi di codice da un piccolo dispositivo medico a un sistema operativo di rete). La definizione di "rumore" dipende anche dai criteri per ciò che costituisce un rapporto degno di nota. Da un lato dello spettro, alcuni sviluppatori contrassegnano tutti i rapporti che non risolvono come "falsi" (anche il codice scritto male che non hanno il tempo di riparare) e dall'altro,

Alcuni di questi strumenti sono più focalizzati sull'analisi centrale e altri sono più focalizzati sul desktop, sebbene tutti e tre abbiano funzionalità che supportano entrambi. Come accennato da @Bob, costano denaro.

Nella mia precedente azienda abbiamo utilizzato l'analizzatore statico di Parasoft. E si riteneva all'interno del team che almeno il 60% dei bug del tempo di esecuzione fossero stati rilevati prima della compilazione.

L'analisi statica può anche essere eseguita senza strumenti, eseguendo revisioni manuali sul codice del software. Questo è spesso il modo più economico per migliorare la qualità del codice.

La seconda opzione migliore è quella di investire per uno o più strumenti di analisi statica di fascia alta (come Coverity o KLOCwork precedentemente menzionati). Poiché questi strumenti eseguono analisi molto più approfondite della lanugine, ad esempio, il rapporto segnale-rumore è molto migliore.

Considero l'utilizzo di lanugine come terza opzione, a causa dell'elevato livello di rumore. Applicare lanugine a un progetto esistente può essere un compito scoraggiante.

In generale, l'analisi dei programmi statici è progredita molto negli ultimi anni. Gli attuali strumenti di analisi statica sono in grado di eseguire analisi interprocedurali profonde, in grado di identificare automaticamente, ad esempio, le pre e post condizioni. Questo può essere di grande aiuto anche per le successive revisioni del codice.

A causa dell'alta percentuale di falsi positivi, non dovresti usare uno strumento di analisi statica (come lint o FindBugs) per ogni compilation.

Piuttosto, è un buon controllo di sanità mentale da consultare una volta che hai un bug e non riesci a capirlo . In tal caso, puoi intrattenere i falsi positivi e potresti aver già ristretto le possibili fonti dell'errore. Ad esempio, se riproduci il tuo bug senza nemmeno eseguire alcun modulo, puoi ignorare ciò che FindBugs dice per loro. Questo è particolarmente utile quando stai guardando un pezzo di codice e pensi che dica una cosa, mentre il compilatore lo legge letteralmente (come in Java quando hai un equalsmetodo che accetta il tipo di classe anziché Object).

Puoi anche fare in modo che gli strumenti di analisi statica facciano parte del tuo processo di sviluppo: quando uno sviluppatore ottiene una revisione del codice, dovrebbe anche eseguire FindBugs su di esso. In breve, è utile, ma non lo userai spesso come il compilatore o l'editor di testo.