Qu'est-ce que l'analyse de code?
L'analyse de code (auparavant FxCop) est un outil d' analyse statique qui recherche des modèles courants qui peuvent indiquer que quelque chose ne va pas dans le code source. Par exemple, si une instance d'une classe qui implémente IDisposablen'est pas supprimée correctement, l'analyse de code émet un avertissement:
private void DoSomething()
{
var connection = new SqlConnection(...);
this.ChangeSomeData(connection);
}
Il s'agit de l'implémentation correcte du code précédent:
private void DoSomething()
{
using (var connection = new SqlConnection(...))
{
this.ChangeSomeData(connection);
}
}
Comme tous les outils d'analyse statique, l'analyse de code vise à trouver des modèles qui sont lourds (ou simplement ennuyeux) à rechercher manuellement. Par exemple, dans l'exemple précédent, il peut être assez ennuyeux pour un développeur de vérifier si une classe qu'il utilise implémente IDisposable(ou de se souvenir de toutes les classes .NET Framework qui l'implémentent).
Quels projets sont éligibles?
Bien qu'il soit sujet à des faux positifs, comme tous les outils d'analyse statique, il est généralement avantageux de cibler zéro avertissements pour le code critique sans utiliser de suppressions . Dans Visual Studio, l'analyse de code peut être configurée pour s'exécuter au moment de la compilation; si les paramètres du projet spécifient également que les avertissements doivent être traités comme des erreurs, les violations des règles d'analyse de code ne resteront pas inaperçues.
Étant donné que l'analyse statique peut prendre un certain temps pour les projets de moyenne ou grande envergure, il est souvent judicieux de la déplacer des machines du développeur vers le serveur de génération TFS. Bien que l'analyse de code pendant la pré-validation ne soit pas une bonne idée (contrairement à StyleCop), elle peut toujours s'exécuter sur la génération et échouer si des avertissements sont trouvés.
Pour le code non critique pour l'entreprise, l'analyse de code peut être exécutée manuellement à partir de Visual Studio ou de la ligne de commande. Les vérifications et avertissements peuvent être affinés dans les propriétés du projet en fonction de vos besoins. Par exemple, les avertissements de mondialisation peuvent être désactivés si votre projet n'est pas destiné à être localisé.
Comme avec StyleCop, il est essentiel de décider si le projet ciblera zéro avertissements de l'analyse de code dès le début du projet. L'introduire dans un projet existant peut être trop douloureux.
Est-ce différent de StyleCop?
Notez que l'analyse de code n'est pas la même chose que StyleCop . La première différence est que l'analyse de code fonctionne avec l'assembly compilé, tandis que StyleCop fonctionne avec la source elle-même. La deuxième différence (et la plus importante) est que l'analyse de code recherche les motifs pouvant indiquer un bogue, tandis que StyleCop applique simplement les règles de style, une convention simple utilisée par votre équipe.
L'analyse de code est également particulièrement utile pour les débutants qui ne connaissent pas très bien la langue , car elle peut souvent conduire à "Aha!" des moments. Par exemple, CA2105: Les champs de tableau ne doivent pas être en lecture seule peuvent conduire quelqu'un à découvrir que même si un tableau est marqué en lecture seule, il ne le rend pas immuable, car rien n'interdit de modifier les éléments dans le tableau. StyleCop ne conduit pas à des découvertes: il n'y a rien d'intéressant à savoir que les champs commencent par une lettre minuscule ou que les appels locaux doivent être préfixés this.
Même si certaines règles sont appliquées à la fois par l'analyse de code et par StyleCop (comme CA1707: les identificateurs ne doivent pas contenir de traits de soulignement par rapport à SA1310: les noms de champ ne doivent pas contenir de soulignement ), ces deux outils sont complémentaires et souvent utilisés côte à côte.
Nous avons déjà des revues de code
La présence de revues de code n'est pas une raison pour éviter l'analyse de code. L'analyse de code et StyleCop sont excellents pour trouver automatiquement les choses avant une révision de code. Il n'y a rien de pire que de passer une revue de code pour identifier les problèmes de style ou les modèles problématiques qui auraient pu être détectés automatiquement. Gardez les revues de code pour des choses intéressantes.
Un autre aspect est que les évaluateurs humains ne sont pas nécessairement bons pour repérer les problèmes détectés par l'analyse de code. Par exemple, une instance d'une implémentation de classe IDisposablepeut être créée dans un emplacement, puis supprimée dans un emplacement différent. Il faudra un certain temps à un réviseur pour le trouver, alors qu'il ne faut que quelques millisecondes à un outil d'analyse statique pour le découvrir.
