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

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

Abbiamo gettato circa 18 GB di codice C e C ++ sia open-source che proprietario, e tracciare attraverso i percorsi del codice e trovare rapidamente bug sottili che richiederebbero un essere umano per sempre a rintracciare. È stato anche bello individuare le cose che normalmente sarebbero state Heisenbugs.

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

Il gotcha è, Coverity è molto costoso. Non pubblicano i costi, ma ho la sensazione che per i progetti commerciali, inizi a centinaia di migliaia di dollari all'anno. Ma probabilmente ci ha risparmiato il dover assumere un gruppo intero di sviluppatori e personale addetto al controllo qualità, quindi nel complesso la nostra gestione sembrava pensare che fosse un buon acquisto.

Avendo avuto quell'esperienza, sono piuttosto favorevole all'analisi del codice statico.

Quando inizi con una nuova lingua è bello avere un allenatore. È così che penso agli strumenti di analisi statica. Scrivo un sacco di javascript e all'inizio ho preso alcune cattive abitudini principalmente perché stavo trasferendo alcune cose dalle lingue precedenti. Javascript è abbastanza flessibile, quindi puoi farla franca praticamente con qualsiasi cosa, ma se avessi jslint che mi avvisa di certi pattern, avrei raccolto schemi di codifica migliori fin dall'inizio, invece di dover imparare di nuovo materiale più tardi.

Gli analizzatori statici sono fondamentalmente recensioni di codici macchina assistita. Indicheranno le aree discutibili che potrebbero essere saltate durante i test periodici.

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

if (x = 1) {
    ...
}

O forse un debuttante confonde il casting lessicale:

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

Certamente gli analizzatori statici richiedono un ritocco. Inoltre, il controllo delle revisioni, i wiki, i bug tracker, le belle stampanti e altri strumenti richiedono un po 'di configurazione. Più grande è il progetto, migliore è la ricompensa per il lavoro iniziale.

Dal punto di vista di un consulente, ogni strumento di analisi statico avrà un certo 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 si sintonizzano e si modificano alcuni di più si ottengono risultati migliori in genere (dopo tutto, gli analizzatori statici devono essere in grado di eseguire 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. A un'estremità dello spettro, alcuni sviluppatori contrassegnano tutti i report che non risolvono come "falso" (anche codice scritto male che non hanno il tempo di sistemare) e dall'altra parte, abbiamo lavorato con diversi mil-aero e le aziende di dispositivi medici che si sono assicurati che anche i falsi positivi fossero "corretti" perché se il codice confondeva lo strumento, allora probabilmente dovrebbe essere scritto in modo più chiaro in modo da essere più mantenibile.

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

Nella mia precedente azienda abbiamo utilizzato l'analizzatore statico di Parasoft. E si credeva all'interno del team che almeno il 60% dei bug di run time fosse stato catturato prima della compilazione.

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

La seconda opzione migliore è investire per uno o più strumenti di analisi statica di fascia alta (come Coverity o KLOCwork). Dato che questi strumenti eseguono analisi molto più approfondite rispetto al lint, ad esempio, il rapporto segnale / rumore è molto migliore.

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

In generale, l'analisi statica dei programmi ha registrato notevoli progressi negli ultimi anni. Gli attuali strumenti di analisi statica sono in grado di eseguire analisi interprocedurali profonde, e possono identificare automaticamente per esempio le condizioni pre e post-procedura. Questo può essere di grande aiuto anche per le revisioni successive del codice.

A causa dell'elevato tasso di falsi positivi, non dovresti utilizzare uno strumento di analisi statico (come lint o FindBugs) per ogni compilation.

Piuttosto, è un bel controllo di integrità consultare una volta che hai un bug e non riesci a capirlo . In tal caso, puoi intrattenere i falsi positivi e potresti aver già ridotto le possibili fonti dell'errore. Ad esempio, se riproduci il tuo bug senza nemmeno eseguire alcuni moduli, puoi ignorare ciò che FindBugs dice per loro. Questo è particolarmente utile quando si guarda un pezzo di codice e pensa si dice una cosa, mentre il compilatore lo legge letteralmente (come in Java quando si ha un metodo equals che prende in tipo della classe anziché Object ).

Puoi anche far sì che 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 tanto spesso quanto il compilatore o l'editor di testo.