L’analyse d’un projet sur le cockpit se base sur des techniques d’analyse statique. Pour cela un certain nombre d’éléments doivent être fournis à la création d’une nouvelle analyse.
On distingue trois catégories d’éléments :
- les fichiers sources (*.cs / *.java)
- les fichiers générés issus de la compilation (*.dll / *.jar)
- les librairies référencées par le projet (*.dll / *.jar)
Les fichiers sources servent lors de l’analyse pour le calcul de certaines métriques, tel que le nombre de lignes de code, la recherche de violations de pratiques et la recherche des duplications. C’est également à partir de ces fichiers que sera généré le code source navigable vous permettant d’accéder à l’origine d’une violation directement depuis le cockpit.
Les fichiers générés à la compilation, quant à eux, sont utilisés d’une part pour extraire les éléments structurant le code (classes, interfaces, méthodes…), ces éléments serviront à l’agrégation des mesures qualités effectuées. D’autre part d’autres métriques (nombre d’instructions, complexité cyclomatique…) et violations de pratique seront également extraits de ces fichiers.
Les librairies, enfin, même si elles ne sont pas directement analysées sont utiles lors de la recherche des violations de pratiques.
Prenons l’exemple de la pratique NeverMakeCtorCallOverridableMethod qui teste qu’il n’y ait pas d’appel à une méthode virtuelle dans un constructeur. Cette règle va vérifier, pour chaque méthode appelée dans un constructeur, si elle est virtuelle. Si la méthode est définie dans une librairie, la déclaration doit être accessible.
En simplifiant on peut considérer que les fichiers sources permettent des analyses à un niveau syntaxique. Alors que les fichiers binaires permettent d’avoir accès à la structure du code, aux chaînes d’appel des méthodes, aux dépendances, mais aussi aux instructions (MSIL/CIL pour le C# ou bytecode pour le Java).
C’est cette combinaison qui permet d’avoir des résultats complémentaires et approfondis sur le cockpit.
Dernier point à prendre en compte, afin d’avoir des résultats cohérents, tous les éléments doivent être synchrones : les fichiers sources doivent être ceux ayant servi a généré les fichiers compilés et les librairies doivent avoir la même version que celle utilisée dans le code. C’est pour éviter ces problèmes et faciliter le processus que nous fournissons des outils de packaging s’interfaçant aux outils standards (MSBuild, Team Foundation System, Ant, Maven, Hudson…). Ils feront l’objet de prochains billets.
