web-dev-qa-db-fra.com

Quel est le but de l'analyse de code et quand dois-je l'utiliser?

J'ai entendu parler de l'analyse de code de Visual Studio, mais je n'en ai jamais utilisé. J'ai lu MSDN , mais je ne comprends toujours pas l'utilisation réelle de l'analyse de code.

N'est-ce pas la même chose que StyleCop?

Quelque part, FxCop a également été mentionné. Quelle est la différence avec l'analyse de code?

Dois-je utiliser l'analyse de code pour chaque projet? Les révisions de code effectuées par mes collègues sont-elles insuffisantes?

c#.netcode-qualitystatic-analysis
26
Arseni Mourzenko

Qu'est-ce que l'analyse de code?

Analyse de code (auparavant FxCop) est un outil analyse statique qui recherche modèles courants qui peut indiquer que quelque chose ne va pas dans le code source. Par exemple, si une instance d'une classe qui implémente IDisposable n'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 est destinée à 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 aux faux positifs, comme tous les outils d'analyse statique, il est généralement avantageux de cibler zéro avertissement pour le code critique sans utiliser 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'exécution de l'analyse de code pendant la pré-validation soit ce n'est 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 depuis Visual Studio ou en 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, avertissements de mondialisation peut être désactivé 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 peut 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 changer les éléments du tableau. StyleCop ne mène 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 par 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 vs 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 revue 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 trouvés automatiquement. Gardez les revues de code pour des trucs intéressants.

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 classe implémentant IDisposable peut être créée à un emplacement, puis supprimée à 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.

36
Arseni Mourzenko