IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Intégration Continue avec Visual Studio et Team Foundation Server - Partie I, Présentation de MsTest et de Static Code Analysis


précédentsommairesuivant

X. Analyse Statique de Code : Corriger les erreurs

X-A. Corriger une erreur

Lorsque votre projet a été paramétré et que vous lancez l'analyse statique de code, un certain nombre d'avertissements et/ou d'erreurs vont être levés. (15)

Vous avez trois solutions pour corriger un avertissement/erreur ;

  • modifier les paramètres de l'analyse statique de code pour ignorer l'erreur levée (voir la section Paramétrage des règles) ;
  • corriger le code pour qu'il satisfasse la règle de l'analyse statique de code. Pour cela, on peut se reporter à la documentation et aux exemples de la MSDN ;
  • désactiver la vérification de l'analyse de code pour l'élément sélectionné.

Comme chaque règle est identifiée de façon unique, vous pouvez supprimer la vérification pour une méthode spécifique. Pour ce faire, vous pouvez cliquer (bouton droit) sur le message et choisir « Suppress Message(s) ».

Vous pouvez alors choisir l'emplacement où sera stockée votre suppression : au-dessus de la méthode elle-même, ou dans un fichier de suppression global.

Suppression de la vérification d'une règle d'analyse statique via attribut
Sélectionnez
[System.Diagnostics.CodeAnalysis.SuppressMessage( 
    "Microsoft.Naming", "CA1706:ShortAcronymsShouldBeUppercase")]

X-B. Corriger plusieurs erreurs

Il n'est pas possible de supprimer plusieurs erreurs avec un seul attribut « SuppressMessageAttribute ». En effet, cela permettrait certes de corriger plusieurs erreurs existantes, mais aussi de corriger toutes les erreurs du même type à venir, ce qui pourrait avoir des conséquences dramatiques en termes de sécurité, performance…

Si une erreur peut être ignorée à l'heure actuelle - on connaît précisément la raison pour laquelle on a écrit le code et on peut donc accepter qu'il brise une règle - on ne peut être garant a priori du code futur.

X-C. Regrouper les suppressions dans un même fichier

X-C-1. Syntaxe du fichier de suppression global

Cependant certains éléments du code ne sont pas liés à un emplacement (fichier) fixe. C'est typiquement le cas d'un namespace. Par conséquent, il ne serait pas judicieux d'ajouter un attribut « SuppressMessageAttribute » dans un fichier plutôt que dans un autre.

Visual Studio nous offre la possibilité de créer un fichier global qui peut contenir une liste de suppressions d'erreurs. Notez que ce n'est que depuis la version 2008 que Visual Studio nous laisse le choix du positionnement des erreurs que l'on supprime.

Ce fichier – nommé « GlobalSuppressions.cs » ou « GlobalSuppressions.vb » se trouve à la racine du projet concerné et va contenir par exemple les lignes suivantes :

Suppression d'erreurs - Correction via fichier global
Sélectionnez
[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Naming", 
           "CA1705:LongAcronymsShouldBePascalCased", 
           Scope = "namespace", 
           Target = "MyRootNamespace")]
[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Performance", 
           "CA1805:DoNotInitializeUnnecessarily", 
           Scope = "member", 
           Target = "MyRootNamespace.MyClass..ctor()")]
[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", 
           "CA2215:DisposeMethodsShouldCallBaseClassDispose", 
           Scope = "member", 
           Target = "MyRootNamespace.MyClass.Dispose(System.Boolean):System.Void")]

On retrouve la même syntaxe que dans les attributs « traditionnels », mais on retrouve deux paramètres nommés supplémentaires : « Scope » et « Target ».

Scope nous permet de préciser le type d'objet que l'on cible. En pratique seuls namespace et member seront utilisés.

Target quant à lui spécifie l'objet pour lequel on veut supprimer l'erreur. On doit toujours préciser le nom complet, namespace inclus.

Notez que pour une méthode, on doit utiliser la syntaxe « Type.NomMethode([TypeParamètre1[, TypeParametre2[…]]]):TypeRetour » ou chaque « Type » correspond en fait a son FullName, soit « Namespace[.ChildNamespace[…]].Type ».

X-C-2. Préciser des méthodes avec noms réservés en IL

Certaines méthodes du framework ont des noms réservés lors de la compilation en code IL. Pour connaître ces différents noms, il « suffit » de connaître le code qui est généré par le compilateur. ILDASM ou Reflector.NET pourra donc vous montrer le nom correct de votre méthode.

Pour citer quelques exemples, on pourra noter :

Liste de quelques méthodes aux noms générés par le compilateur

Nom

Définition

.ctor()
.ctor([Parameters])

Constructeur de la classe

 
Sélectionnez
public class Class1
{
   public Class1() { }
}

.cctor()

Constructeur statique de la classe

 
Sélectionnez
public class Class1
{
   static Class1() { }
}

Finalize():System.Void

Destructeur de la classe

 
Sélectionnez
public class Class1
{
   ~Class1() { }
}

op_Implicit
op_Explicit
op_Addition
op_Subtraction
op_Division
op_Multiply
op_Equality
op_Inequality
op_LessThan
op_GreaterThan
op_LessThanOrEqual
op_GreaterThanOrEqual
op_LeftShift.

Quelques-uns des opérateurs que l'on peut surcharger sur une classe
Dans les exemples ci-dessous, l'implémentation sera toujours omise.

 
Sélectionnez
public class Class1
{
   public static implicit operator Class1(string b) {}
   public static explicit operator Class1(double b) {}
   public static Class1 operator +(Class1 a, Class1 b) {}
   public static Class1 operator -(Class1 a, Class1 b) {}
   public static Class1 operator /(Class1 a, Class1 b) {}
   public static Class1 operator *(Class1 a, Class1 b) {}
   public static Class1 operator ==(Class1 a, Class1 b) {}
   public static Class1 operator !=(Class1 a, Class1 b) {}
   public static Class1 operator <(Class1 a, Class1 b) {}
   public static Class1 operator >(Class1 a, Class1 b) {}
   public static Class1 operator <=(Class1 a, Class1 b) {}
   public static Class1 operator >=(Class1 a, Class1 b) {}
   public static Class1 operator <<(Class1 a, int i) {}
}

X-C-3. Renommer le fichier de suppression global

Si vous désirez utiliser un autre nom de fichier, vous pouvez éditer le fichier de projet (.csproj / .vbproj) et ajouter la ligne suivante (où [name] est le nouveau nom du fichier - sans chemin):

Changer le nom du fichier de suppression global
Sélectionnez
<PropertyGroup>
    <CodeAnalysisModuleSuppressionsFile>[name]</CodeAnalysisModuleSuppressionsFile>
</PropertyGroup>

XI. Analyse Statique de Code : Limitations

Le moteur d'analyse statique de code a bien évolué entre les versions 2005 et 2008 de Visual Studio.

La première version en effet ne détectait pas toujours les erreurs les plus simples si celles-ci étaient « cachées » dans des méthodes anonymes. Cependant ces erreurs ont été corrigées depuis.

À mon sens, et autant que je connaisse l'outil, je ne vois que deux limitations :

  • la possibilité de définir facilement des règles standards sur une solution au complet, règles qui pourraient être affinées de projet en projet. Ces règles standards pourraient même être mises au niveau des settings de Visual Studio, et ainsi être exportées ;
  • l'impossibilité de créer de nouvelles règles d'analyse statique de code, comme nous le permettait FxCop.

précédentsommairesuivant
Notez d'ailleurs que l'analyse statique de code est limitée à 200 avertissements / erreurs. Il est donc important de bien paramétrer votre projet pour que les erreurs soient vraiment parlantes.
Cependant une bonne pratique est d'avoir toujours comme objectif zéro avertissement levé par l'analyse statique de code.

Copyright © 2009 Pierre-Emmanuel Dautreppe . Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC.