Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

La qualité de code a toujours été un sujet épineux. Nombre de sociétés qui ne s'y sont jamais vraiment intéressées, et qui veulent soudainement sauter le pas, passent d'un outillage quasi inexistant à un outillage qui finit par décourager les développeurs.

Dans une démarche DevOps, ceci n'est pas envisageable. Heureusement, il existe un juste milieu. Du moins, un bon outil dédié à la qualité de code est censé nous permette d'avoir le contrôle sur les règles appliquées (sélection, affichage, documentation, aide à la résolution...). Avant de mettre en place un tel outil, il faut donc prendre un peu de temps pour découvrir ses possibilités, et vérifier qu'elles sont bien en adéquation avec le besoin. Ceci ne se fait pas en 5 minutes, car plus on a de projets, et de technologies différentes, et plus on a de prérequis à valider.

La solution 100% .net

En attendant, pour les développeurs .net il est possible d'améliorer la qualité de son code sans installer quoi que ce soit. Il suffit de configurer Code Analysis. La fonctionnalité n'est pas nouvelle, mais je suis toujours étonnée de rencontrer des développeurs ne la connaissant pas.

En pratique

Pour profiter de Code Analysis pour la totalité des projets d'une solution, le plus simple consiste créer un fichier Directory.Build.props à côté de sa solution, et d'y glisser les propriétés suivantes (pour forcer l'analyse lors de la build) :

<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
<AnalysisMode>minimum</AnalysisMode>

On peut ensuite jouer avec la propriété AnlasysisMode comme spécifié ici : Code analysis in .NET | Microsoft Learn

La documentation peut aussi vous permettre de choisir des règles à appliquer au cas par cas.

Pour aller un peu plus loin

Si vous n'avez jamais utilisé Code Analysis, il ne faut pas avoir peur de procéder par paliers. Dans un premier temps on peut choisir un niveau minimum. Dès que la solution est conforme, on peut passer au niveau suivant.

Personnellement, je préfère ne pas casser la build alors qu'une équipe adopte Code Analysis. J'opte donc pour une solution en deux temps :

1. La compilation en mode Release doit se faire avec un niveau de règle accepté par tous.
2. La compilation en mode Debug peut se faire avec un mode un peu plus exigeant.

De la sorte, lors de leur travail quotidien, les développeurs ont un IDE qui leur remonte des warnings pour les encourager à améliorer le niveau de qualité du projet. Attention : on parle de quelques warnings, pas des milliers. Il ne faut pas décourager les développeurs.

Exemple de configuration possible pour cela :

<PropertyGroup Condition="$(Configuration)=='Debug'">
  <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  <AnalysisMode>recommended</AnalysisMode>
</PropertyGroup>
<PropertyGroup Condition="$(Configuration)=='Release'">
  <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  <AnalysisMode>minimum</AnalysisMode>
</PropertyGroup>

Les plus téméraires voudront peut-être ajouter un EnforceCodeStyleInBuild. C'est une histoire de gouts. Mais attention, il faut que l'équipe adhère à cette pratique. Il ne faut pas qu'elle le subisse. Faute de quoi, le niveau de qualité ne pourra pas augmenter.

<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>