Analisi del codice statico: quali attivare prima?

Question

Stiamo usando VS2008 con il set di regole di analisi del codice statico incorporato.
Abbiamo una soluzione C # relativamente grande (oltre 150 progetti) e mentre alcuni progetti (& Lt; 20) usano religiosamente l'analisi del codice statico, la maggior parte no. Vogliamo iniziare a far applicare l'analisi del codice statico su tutti i progetti, ma abilitare tutte le regole creerebbe una forte distrazione per i nostri progetti attuali. Quale delle molte regole di analisi del codice statico disponibili dovremmo attivare per prima? Quali regole hanno il più grande successo? Se potessi darmi la tua top 20 prioritaria, lo apprezzerei molto.
Grazie in anticipo,
--Ed.S.

Answer 1

Le primissime regole che dovresti attivare per un progetto sono quelle per le quali non hai ancora violazioni in quel progetto. Ciò ti consentirà di evitare di introdurre nuovi problemi senza costi aggiuntivi per la pulizia.

Per il resto, dato che stai già utilizzando l'analisi del codice su altri progetti, il tuo miglior input per cui è più probabile che le regole vengano infrante con gravi conseguenze sono probabilmente gli sviluppatori che lavorano su quei progetti. Se non hai abbastanza sovrapposizioni tra i progetti per ottenere un feedback significativo dagli sviluppatori, potresti prendere in considerazione l'idea di iniziare con le regole incluse in Regole minime consigliate Microsoft impostate in Visual Studio 2010.

Se stai pianificando di eliminare effettivamente le violazioni esistenti in un dato progetto, potresti voler considera l'utilizzo di FxCop invece di VS Code Analysis fino al completamento della pulizia. Ciò consentirebbe di attivare immediatamente le regole mantenendo & Quot; per la pulizia & Quot; esclusioni di violazioni esistenti al di fuori del tuo codice sorgente.

Answer 2

Dato che quelli di Studio sono simili alle regole di FxCop, posso dirti quali avrei attivato ultimo .

Se l'internazionalizzazione non è all'orizzonte, disattiva le Regole di globalizzazione.

Disattiva inizialmente le Regole di prestazione. Ottimizza quando è necessario.

Adatta gli altri al tuo team e ai tuoi progetti. Disattiva le singole regole che non sono applicabili. In particolare, potrebbe essere necessario modificare le regole di denominazione.

EDIT: la cosa più importante è ridurre il rumore. Se ogni progetto ha 200 avvisi e rimane tale per mesi, tutti li ignoreranno. Attiva le regole che contano per il tuo team, ripulisci il codice per ottenere il passaggio del 100% (o elimina le eccezioni - e ci saranno eccezioni; queste sono linee guida), quindi applica mantenendo pulito il codice.

Answer 3

Se hai intenzione di localizzare il tuo progetto / verrà utilizzato in diversi paesi, abilita sicuramente le regole di localizzazione. Troverà tutte le chiamate a tutti i tipi di funzioni Format / Parse che non specificano CultureInfo. I bug che coinvolgono CultureInfo non specificato sono difficili da trovare nei test, ma ti morderanno davvero nel culo, quando il tuo cliente francese ti chiederà: perché il tuo programma non funziona / si blocca sui numeri con & Quot;, & Quot ; come separatore decimale.

Answer 4

Nella mia esperienza, gli avvisi di analisi del codice di tutti i tipi mostrano bug o difetti "nascosti" nel codice. Risolvere questi problemi può risolvere alcuni problemi reali. Non ho trovato un elenco di avvisi che vorrei disabilitare.

Invece, li accenderei su un progetto alla volta e sistemerei tutti gli avvertimenti in quel progetto prima di passare al successivo.

Se si desidera disattivare le cose, prenderei in considerazione la possibilità di non controllare le regole di denominazione (a meno che non si spedisca una libreria, API o altri metodi esposti esternamente) e le regole di globalizzazione. (a meno che le applicazioni non utilizzino attivamente la globalizzazione). Dipende un po 'dalla tua situazione che ha senso.

Answer 5

Sono in qualche modo d'accordo con la risposta di Jeroen Huinink .

Vorrei attivare tutte le regole che ritieni debbano seguire un progetto e risolverle il prima possibile. Non è necessario risolverli tutti ora, ma mentre si procede attraverso la correzione di un difetto o del refactoring di un metodo in un modulo, è sempre possibile eliminare i problemi rilevati dall'analisi statica in quel metodo o modulo. Il nuovo codice dovrebbe aderire alle tue regole e il codice esistente dovrebbe essere trasformato in aderenza il più rapidamente possibile, ma non è necessario eliminare tutto per farlo accadere.

Il tuo team di sviluppo può anche esaminare i problemi di un progetto e dargli delle priorità, magari archiviando i difetti nel sistema di tracciamento dei problemi per i problemi più critici in modo che vengano risolti rapidamente e dallo sviluppatore appropriato.