Ho sentito dell'analisi del codice di Visual Studio ma non ne ho mai usato uno. Ho letto MSDN , ma ancora non capisco il vero uso dell'analisi del codice.
Non è lo stesso di StyleCop?
Da qualche parte, è stato anche menzionato FxCop. Qual è la differenza con l'analisi del codice?
Devo usare l'analisi del codice per ogni progetto? Le revisioni del codice eseguite dai miei colleghi sono insufficienti?
Risposte:
L'analisi del codice (precedentemente FxCop) è uno strumento di analisi statica che cerca schemi comuni che potrebbero indicare che qualcosa non va nel codice sorgente. Ad esempio, se un'istanza di una classe che implementa IDisposablenon è disposta correttamente, l'analisi del codice emetterà un avviso:
private void DoSomething()
{
var connection = new SqlConnection(...);
this.ChangeSomeData(connection);
}
Questa è la corretta implementazione del precedente pezzo di codice:
private void DoSomething()
{
using (var connection = new SqlConnection(...))
{
this.ChangeSomeData(connection);
}
}
Come qualsiasi strumento di analisi statica, l'analisi del codice ha lo scopo di trovare modelli che siano ingombranti (o semplicemente noiosi) da trovare manualmente. Ad esempio, nell'esempio precedente, può essere abbastanza noioso per uno sviluppatore verificare se una classe che utilizza implementa IDisposable(o ricordare tutte le classi .NET Framework che la implementano).
Sebbene sia soggetto a falsi positivi, come qualsiasi strumento di analisi statica, di solito è utile indirizzare gli avvisi zero per il codice business-critical senza utilizzare le soppressioni . All'interno di Visual Studio, l'analisi del codice può essere configurata per l'esecuzione in fase di compilazione; se le impostazioni del progetto specificano anche che gli avvisi devono essere trattati come errori, le violazioni delle regole di analisi del codice non rimarranno inosservate.
Poiché l'analisi statica può richiedere del tempo per progetti di medie o grandi dimensioni, è spesso una buona idea spostarla dalle macchine degli sviluppatori al server di build TFS. Durante l'esecuzione dell'analisi del codice durante il pre-commit non è una buona idea (a differenza di StyleCop), può comunque essere eseguito su build e fallire se vengono trovati avvisi.
Per il codice non critico per l'azienda, l'analisi del codice può essere eseguita manualmente da Visual Studio o dalla riga di comando. I controlli e gli avvisi possono essere dettagliati nelle proprietà del progetto in base alle proprie esigenze. Ad esempio, gli avvisi di globalizzazione possono essere disattivati se il progetto non è destinato alla localizzazione.
Come con StyleCop, è essenziale decidere se il progetto avrà come target zero avvisi dall'analisi del codice dall'inizio del progetto. Presentarlo in un progetto esistente potrebbe essere troppo doloroso.
Si noti che l'analisi del codice non è la stessa cosa di StyleCop . La prima differenza è che l'analisi del codice funziona con l'assembly compilato, mentre StyleCop funziona con l'origine stessa. La seconda (e più importante) differenza è che l'analisi del codice cerca schemi che potrebbero indicare un bug, mentre StyleCop sta semplicemente applicando le regole di stile, una semplice convenzione utilizzata dal tuo team.
L'analisi del codice è inoltre particolarmente utile per i principianti che non conoscono molto bene la lingua , poiché spesso può portare a "Ah!" momenti. Ad esempio, CA2105: i campi dell'array non devono essere letti solo può portare qualcuno a scoprire che anche se un array è contrassegnato come di sola lettura, non lo rende immutabile, dal momento che nulla proibisce di modificare gli elementi all'interno dell'array. StyleCop non porta a scoperte: non c'è niente di interessante nel sapere che i campi iniziano con una lettera minuscola o che è necessario aggiungere il prefisso alle chiamate locali this.
Anche se alcune regole sono applicate sia dall'analisi del codice sia da StyleCop (come CA1707: gli identificatori non devono contenere caratteri di sottolineatura rispetto a SA1310: i nomi dei campi non devono contenere caratteri di sottolineatura ), questi due strumenti sono complementari e spesso utilizzati fianco a fianco.
La presenza di revisioni del codice non è un motivo per evitare l'analisi del codice. Sia l'analisi del codice che StyleCop sono eccellenti nel trovare automaticamente le cose prima di una revisione del codice. Non c'è niente di peggio che spendere una revisione del codice per individuare problemi di stile o schemi problematici che avrebbero potuto essere trovati automaticamente. Mantieni recensioni di codice per cose interessanti.
Un altro aspetto è che i revisori umani non sono necessariamente bravi a individuare i problemi rilevati dall'analisi del codice. Ad esempio, un'istanza di un'implementazione di classe IDisposablepuò essere creata in una posizione e quindi disposta in una posizione diversa. Ci vorrà del tempo prima che un revisore lo trovi, mentre bastano pochi millisecondi affinché uno strumento di analisi statica lo rilevi.