Ho sentito parlare 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, FxCop è stato anche menzionato. Qual è la differenza con l'analisi del codice?
Devo utilizzare l'analisi del codice per ogni progetto? Le revisioni del codice eseguite dai miei colleghi sono insufficienti?
Analisi del codice (in precedenza FxCop) è un analisi statistica strumento che cerca schemi comuni che possono indicare che qualcosa non va nel codice sorgente. Ad esempio, se un'istanza di una classe che implementa IDisposable non è stata eliminata correttamente, l'analisi del codice emetterà un avviso:
private void DoSomething()
{
var connection = new SqlConnection(...);
this.ChangeSomeData(connection);
}
Questa è l'implementazione corretta del codice precedente:
private void DoSomething()
{
using (var connection = new SqlConnection(...))
{
this.ChangeSomeData(connection);
}
}
Come tutti gli strumenti di analisi statici, l'analisi del codice ha lo scopo di trovare modelli che sono macchinosi (o semplicemente noiosi) da trovare manualmente. Ad esempio, nell'esempio precedente, può essere piuttosto noioso per uno sviluppatore verificare se una classe utilizza le implementazioni IDisposable (o ricordare tutte le classi .NET Framework che lo implementano).
Sebbene sia soggetta a falsi positivi, come qualsiasi strumento di analisi statica, di solito è utile indirizzare zero avvisi per codice business-critical senza utilizzare suppressions . All'interno di Visual Studio, l'analisi del codice può essere configurata per essere eseguita in fase di compilazione; se le impostazioni del progetto specificano anche che gli avvertimenti devono essere considerati come errori, le violazioni delle regole di analisi del codice non passeranno inosservate.
Poiché l'analisi statica può richiedere del tempo per progetti di medie o grandi dimensioni, è spesso una buona idea spostarla dai computer degli sviluppatori al server di sviluppo TFS. L'esecuzione dell'analisi del codice durante il pre-commit è non è una buona idea (a differenza di StyleCop), può ancora essere eseguita su build e fallire se vengono trovati avvisi.
Per il codice non business-critical, l'analisi del codice può essere eseguita manualmente da Visual Studio o riga di comando. I controlli e gli avvisi possono essere dettagliati nelle proprietà del progetto in base alle proprie esigenze. Ad esempio, avvisi di globalizzazione possono essere disattivati se il tuo progetto è non inteso per essere localizzato.
Come per StyleCop, è essenziale decidere se il progetto avrà come target zero avvisi dall'analisi del codice dall'inizio del progetto. Introdurlo in un progetto esistente può essere troppo doloroso.
Nota 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 la fonte stessa. La seconda (e la più importante) differenza è che l'analisi del codice cerca i pattern che possono indicare un bug, mentre StyleCop sta semplicemente facendo rispettare le regole di stile, una semplice convenzione utilizzata dal tuo team.
L'analisi del codice è particolarmente utile per i principianti che non conoscono molto bene la lingua , poiché spesso possono portare a "Aha!" momenti. Ad esempio, CA2105: i campi array non devono essere letti solo maggio portare qualcuno a scoprire che anche se un array è contrassegnato come di sola lettura, non lo rende immutabile, poiché nulla vieta di modificare gli elementi all'interno dell'array. StyleCop non porta a scoperte: non c'è nulla di interessante nel sapere che i campi iniziano con una lettera minuscola o che le chiamate locali devono essere precedute da 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 usati fianco a fianco.
La presenza di revisioni del codice non è un motivo per evitare l'analisi del codice. Sia Code analysis che StyleCop sono eccellenti nel trovare automaticamente prima una revisione del codice. Non c'è niente di peggio che spendere una revisione del codice per individuare problemi di stile o schemi problematici che potrebbero essere stati 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 una classe che implementa IDisposable può essere creata in una posizione e quindi eliminata in una posizione diversa. Ci vorrà del tempo prima che un revisore lo trovi, mentre per scoprirlo basta un paio di millisecondi per uno strumento di analisi statico.
Leggi altre domande sui tag code-quality c# .net static-analysis