9. Analyse Statique de Code : Présentation▲
9-1. 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 ».
9-2. 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 ».
9-3. 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.
9-4. 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
9-4-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.
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.
9-4-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}] | |||
| Où | Règle = {Symbole}{Nom Catégorie}#{CheckId} | ||
| Où | 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) | ||
<PropertyGroup>
<CodeAnalysisRules>-Microsoft.Design#CA2210</CodeAnalysisRules>
</PropertyGroup><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 projet à venir dans la mesure où tous répondront à des besoins spécifiques.
