DISABILITARE ADBLOCK

ADBlock sta bloccando alcuni contenuti del sito

ADBlock errore
risultati trovati: 

DOMANDA

Quali sono alcune delle strategie utilizzate durante l'implementazione dell'analisi FxCop / statica su basi di codice esistenti con violazioni esistenti? Come si possono ridurre nel modo più efficace le violazioni dell'analisi statica?

SOLUZIONE

Inizialmente usa l'attributo [SuppressMessage]. Almeno all'inizio. Una volta ottenuto il conteggio su 0 tramite l'attributo, si inserisce una regola secondo cui i nuovi check-in potrebbero non introdurre violazioni di FxCop.

Visual Studio 2008 ha una bella funzionalità di analisi del codice che ti consente di assicurarti che l'analisi del codice venga eseguita su ogni build e che tu possa considerare gli avvisi come errori. Ciò potrebbe rallentare un po 'le cose, quindi ti consiglio di configurare un server di integrazione continua (come CruiseControl.NET) e di far eseguire l'analisi del codice su ogni check-in.

Dopo averlo controllato e non introducendo nuove violazioni ad ogni check-in, inizia ad affrontare intere classi di violazioni di FxCop alla volta con l'obiettivo di rimuovere i SuppressMessageAttributes che hai usato.

Il modo per tenere traccia di quelli che vuoi davvero conservare è quello di aggiungere sempre un valore di giustificazione a quelli che vuoi veramente sopprimere.

Se ti va lasciaci una tua opinione

L'articolo ti è stato utile ed è tradotto correttamente?

ALTRI SUGGERIMENTI

Riscrivi il tuo codice in uno stile di passaggio!

Seriamente, una vecchia base di codice avrà centinaia di errori, ma è per questo che abbiamo programmatori principianti / stagisti. La correzione delle violazioni di FxCop è un ottimo modo per ottenere una panoramica della base di codice e anche imparare a scrivere codice .NET conforme.

Quindi morde solo il proiettile, bevi molta caffeina e superalo in un paio di giorni!

NDepend sembra potrebbe fare quello che stai cercando, ma non sono sicuro che possa essere integrato in una build automatizzata CruiseControl.Net e fallire la build se il codice non lo fa soddisfare i requisiti (che è quello che vorrei che accadesse).

Altre idee?

Un'alternativa a FxCop sarebbe quella di utilizzare lo strumento NDepend . Questo strumento consente di scrivere Regole di codice su query LINQ C # (ciò che chiamiamo CQLinq ). Dichiarazione di non responsabilità: sono uno degli sviluppatori dello strumento

Più di 200 regole di codice sono proposte per impostazione predefinita. Personalizzare le regole esistenti o creare le proprie regole è semplice grazie alla sintassi ben nota C # LINQ.

Per mantenere basso il numero di falsi positivi, CQLinq offre le esclusive capacità di definire ciò che è l'insieme JustMyCode tramite speciali query di codice precedute da notmycode . Ulteriori spiegazioni su questa funzione sono disponibili qui . Ecco ad esempio due notmycode query predefinite:

Per mantenere basso il numero di falsi positivi, con CQLinq puoi anche focalizzare il risultato delle regole solo sul codice aggiunto o sul refactored del codice, poiché a linea di base definita in passato . Vedi la seguente regola, che rileva i metodi troppo complessi aggiunti o refactored dalla linea di base:

warnif count > 0 
from m in Methods
where m.CyclomaticComplexity > 20 &&
      m.WasAdded() || m.CodeWasChanged()
select new { m, m.CyclomaticComplexity }

Infine, nota che con le regole del codice NDepend è possibile verificare live in Visual Studio e su costruire il tempo di processo, in un generato HTML + rapporto javascript .

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow