Les messages affichés par un compilateur se classent en général en 2 catégories : les erreurs et les « warnings ». Les erreurs imposent une action immédiate, sinon le code ne se compile pas. Les warnings indiquent un problème accessoire.

Vous connaissez sûrement l’outil Checkstyle, qui vérifie l’adhésion de votre code à un guide de style. Les règles sont nombreuses, et lorsqu’on le met en route sur un code existant, les warnings le sont aussi. Parmi tous ces warnings, il y en sûrement quelques-uns qui signalent de vrais bugs.

Il arrive hélas fréquemment qu’on ignore cette liste de warnings, en se disant qu’on va la traiter plus tard. Ce comportement est très hypocrite, parce qu’on sait bien au fond de soi que lorsque le projet sera livré, on passera à autre chose, et que les warnings vont rester.

Face à un warning, il y a 4 options possibles :

1. Corriger le code pour que le warning disparaisse. C’est la meilleure action à faire.

2. Inhiber localement le warning, en l’encadrant de commentaires CHECKSTYLE:OFF et CHECKSTYLE:ON. Il faut toujours ajouter un commentaire texte expliquant la raison pour laquelle la règle n’est pas respectée.

3. Changer le paramétrage de l’outil (compilateur, IDE, Checkstyle, …), pour que le type de problème mentionné ne le soit plus. C’est à dire, considérer ce cas comme normal dans tout le code. Tous les warnings similaires vont disparaître d’un seul coup du code.

4. Laisser traîner le warning. Probablement indéfiniment. C’est la moins bonne action qu’il est possible de faire. Cela revient en fait à ne rien faire. C’est le comportement hypocrite que je dénonce,

Je déconseille très fortement la 4e option. Au point de configurer mes paramètres de compilation pour que les warnings soient des erreurs. Cela impose de les corriger tout de suite, ce qui est souvent très facile à faire, en utilisant l’une des 2 premières options.

On peut considérer que les warnings n’empêchent pas le code de s’exécuter correctement, et ne sont donc pas importants. Le sous-entendu, est que la seule caractéristique qui compte, est le fonctionnement du code. C’est faux. La lisibilité du code est tout aussi importante. Un code lisible est plus facile à comprendre, donc plus facile à faire évoluer ou à maintenir.