Massimo Oliviero

E’ possibile configurare FxCop in modo tale da non fargli analizzare parti di classi o di metodi o addirittura interi assembly. In questo modo è possibile, in gergo, far “sopprimere” un warning di FxCop, inserendo una riga di codice per ogni warning che vogliamo disabilitare.

Per fare questo ci sono due possibilità:

1. Sopprimere un warning inline, cioè su un metodo, una classe o una proprietà specifica
2. oppure un Global Suppressions creando un file cs (o vb) apposito

#define CODE_ANALYSIS
class TaskList
{
   [SuppressMessage("Microsoft.Usage", "CA2227:CollectionPropertiesShouldBeReadOnly")]
   public IList<Task>
   {
       get { return this.tasks; }
       set { this.tasks = value; }
   }
}

Se invece volessimo sopprimere un warning su tutto il nostro assembly (ma magari solo per uno specifico namespace), possiamo creare un generico file GlobalSuppressions.cs e inserire il seguente codice:

#define CODE_ANALYSIS
 
using System.Diagnostics.CodeAnalysis;
 
// con questa direttiva sto disabilitando tutti warning di tipo
// CA1020:AvoidNamespacesWithFewTypes a livello di namespace
// per tutto il name space Azienda.Progetto.Service
[module: SuppressMessage("Microsoft.Design", "CA1020:AvoidNamespacesWithFewTypes", Scope = "namespace", Target = "Azienda.Progetto.Service")]

Come si nota in entrambi gli esempi è necessario definire un simbolo CODE_ANALYSIS in modo da attivare questo tipo di funzionalità. Per avere la direttiva corretta con il warning da sopprimere in maniera facile è sufficente premere tasto destro sul messaggio di warning in FxCop Gui e selezionare Copy As -> SuppressMessage. Il codice necessario sarà copiato negli appunti.

Programmazione .net, fxcop

Ho iniziato da poco un progetto personale in c# per sperimentare una serie di metodologie. Tra le varie cose mi sono imposto di utilizzare due strumenti quali StyleCop e FxCop. Entrambi i tool della Microsoft prevedono una serie di regole di programmazione che vanno dalla documentazione al design del codice. Per un totale di circa 400 regole. Rispettarle tutte è davvero un’impresa ardua, ma i vantaggi sono enormi. Pulizia del codice, standard di scrittura, ottimizzazione delle prestazioni e tanto altro. Sia StyleCop che FxCop si integrano perfettamente in Visual Studio, ed è così possibile verificare in tempo reale le possibili violazioni di una delle regole scelte.

Sia con StyleCop che con FxCop è possibile scrivere, con estrema facilità, nuove regole (rules) custom in modo da espandere le potenzialità di questi due strumenti adattandoli alle nostre esigenze di progetto. Detto questo alcune delle regole che mi sono capitate di affrontare in questi giorni mi hanno lasciato da una parte perplesso e da un’altra stupito. Per esempio la regola CA1726: UsePreferredTerms, è una regola che prevede l’utilizzo di termini nuovi, rispetto a quelli più obsoleti, nei nomi dei membri e delle classi. E’ così che la mia simpatica classe Login non è gradita da StyleCop che mi suggerisce un più moderno termine come LogOn (tra l’altro rispettando il case). Davvero bizzarra come regola no?. Navigando sulla relativa pagina di descrizione della regola ci ritroviamo una tabella di nomi e termini obsoleti con i rispettivi termini moderni.

A parte questa regola le altre le ho trovate molto formative. Soprattutto le regole di StyleCop mi hanno aperto la strada verso un nuovo modo di scrivere codice e mi hanno fatto scoprire aspetti interessanti del framework. Per esempio la regola SA1200: UsingDirectivesMustBePlacedWithinNamespace, prevede che le direttive “using” (solo in c#) dovrebbero essere posizionate all’interno del namespace e non all’esterno come fanno ovviamente tutti e come anche visual studio propone nei suoi template. Perché? Ecco perché:

There are subtle differences between placing using directives within a namespace element, rather than outside of the namespace, including: 

1. Placing using-alias directives within the namespace eliminates compiler confusion between conflicting types. 
2. When multiple namespaces are defined within a single file, placing using directives within the namespace elements scopes references and aliases.

Interessante no? Per il momento le mie riflessioni terminano qui. Posso solo dire che questi due strumenti dovrebbero diventare un must per ogni programmatore che vuole creare codice robusto e di qualità, ma soprattutto standard!.

Programmazione .net, csharp, fxcop, stylecop