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

IX. Analyse Statique de Code : Présentation

IX-A. Activer l'analyse statique de code

L'analyse statique se définit et s'active au niveau du projet. Pour ce faire, il suffit de faire un clic droit sur le projet, et de choisir « Properties ». On peut alors choisir l'onglet « Code Analysis » et activer la case « Enable Code Analysis ».

Paramétrage de l'analyse statique de code
Vue de paramétrage de l'analyse statique de code

IX-B. Lancer l'analyse statique de code

Pour lancer l'analyse statique de code, il suffit de cliquer droit sur le projet et de choisir « Run Code Analysis ».

Résultat de l'analyse statique de code
Visualisation du résultat de l'analyse statique de code

IX-C. Explication du nommage des règles

Chaque règle est caractérisée par

  • une catégorie (par ex. : Microsoft.Naming) ;
  • un code / CheckId (par ex. : CA1707) ;
  • un nom de règle, souvent très parlant et proche du texte affiché dans les propriétés du projet (par ex. : IdentitifiersShouldNotContainUnderscores) ;
  • une indication spécifiant si modifier le code pour corriger l'erreur entraînera des changements brisant la compatibilité (Breaking Change).

Notez que chaque règle est décrite avec précision dans la MSDN. Pour y accéder, il suffit de faire une recherche dans la MSDN en utilisant le code de l'erreur (eg CA1707) ou de simplement appuyer sur « F1 » en sélectionnant l'erreur / avertissement généré par l'analyse statique de code.

On retrouvera notamment des explications sur la raison de mise en application de cette règle, et souvent des exemples de code, violant ou non la règle.

Certaines des règles sont décrites dans la MSDN comme étant « à corriger si applicable ». En effet, cette analyse contient des règles standards dont le suivi va dépendre de l'implémentation mise en place.

IX-D. Paramétrage des règles

Vous pouvez bien entendu paramétrer l'analyse selon le projet sur lequel vous travaillez. Pour cela, vous pouvez :

  • supprimer définitivement (pour le projet courant) l'analyse d'une règle donnée ;
  • spécifier qu'une règle donnée lève soit un avertissement, soit une erreur.

IX-D-1. Paramétrage via l'interface de Visual Studio

Ce paramétrage s'effectue dans les deux cas dans la page de propriétés du projet.

Ignorer une règle
Ignorer des règles d'analyse statique de code

Dans la figure ci-dessus, on spécifie qu'aucune des règles d'interopérabilité ne sera vérifiée. De même on ne vérifiera pas la règle CA1700 alors que la règle CA1701 lèvera une erreur et non avertissement.

IX-D-2. Paramétrage via fichier de projet

Pour le moment les règles d'analyses sont propres à un projet et il n'est pas possible de les importer de projet en projet ou encore de les spécifier sur une solution.

La seule solution pour pallier cette lacune serait de créer son propre template de projet, template qui pourrait alors comporter la liste des erreurs qui sont ignorées dans ce projet. En effet, le paramétrage des règles d'analyse statique de code se reflète au niveau du fichier de projet (.csproj ou .vbproj).

Il s'agit en effet d'une propriété CodeAnalysisRules dont le format est le suivant :

       
 

CodeAnalysisRules = {Règle}[;{CodeAnalysisRules}]

Règle = {Symbole}{Nom Catégorie}#{CheckId}

Symbole =

-

pour ignorer une règle

   

+!

pour demander de lever une erreur si la règle n'est pas respectée (et non un simple avertissement)

 

Nom Catégorie

est le nom de la catégorie de l'erreur (ex Microsoft.Naming)

 

CheckId

est le code de l'erreur (ex CA1707)

Spécifier dans un projet qu'une règle est ignorée
Sélectionnez
<PropertyGroup>
  <CodeAnalysisRules>-Microsoft.Design#CA2210</CodeAnalysisRules>
</PropertyGroup>
Spécifier dans un projet qu'une règle lèvera une erreur
Sélectionnez
<PropertyGroup>
  <CodeAnalysisRules>+!Microsoft.Design#CA2210</CodeAnalysisRules>
</PropertyGroup>

Dans la première source, on spécifie qu'une règle spécifique est ignorée : ici la règle CA2210 de la catégorie « Microsoft.Design ».

Dans la seconde source par contre, on spécifie que cette même règle sera vérifiée et qu'elle provoquera une erreur au lieu d'un avertissement.

Si on veut spécifier plusieurs règles, il suffit de les séparer par un « ; ».

Notez cependant qu'il est très délicat de fixer des règles interdites pour tous les types de projets à venir dans la mesure où tous répondront à des besoins spécifiques.


précédentsommairesuivant

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.