août
2009
Aujourd’hui, j’ai découvert l’annotation javax.annotation.Generated. Je n’ai jamais vu d’utilisation concrète de cette annotation, et c’est bien dommage.
Voici idéalement ce qui devrait exister…
Les générateurs de code
Tout d’abord, il faudrait que tous les outils qui génèrent du code fasse apparaître cette annotation. Voici quelques exemples (que j’utilise quotidiennement) :
- wsdl2java et les stubs Axis2
- javacc
- Magic Draw (et tous les outils d’UML)
- XmlBeans
Je pense que je vais soumettre cette idée dans les différents bug trackers de ces outils, n’hésitez pas à faire de même de votre côté.
Les IDE
Les IDE devraient exploiter cette balise en empêchant le développeur de modifier du code marqué comme @Generated. Bien sûr, le développeur peut retirer la balise et faire des modifs custo, mais dans ce cas le code devient du code qui sera considéré comme manuel. On peut même imaginer que les générateurs de code vérifient la présence de la balise avant d’écraser le code lors de générations ultérieures.
Question subsidiaire : comment empêcher un fourbe développeur de supprimer l’annotation, faire des modifs, puis remettre l’annotation ???
Les outils d’analyse de code
C’est là que ça devient très intéressant. Dans ma société nous utilisons beaucoup d’outils de mesure de la qualité du code. Liste non exhaustive :
- PMD
- Checkstyle
- Findbugs
- Cobertura
- Et Sonar pour piloter le tout
Il est très pénible de devoir configurer chacun de ces outils pour ignorer le code généré. En effet, ce code ne doit pas rentrer dans l’analyse d’un projet, car souvent :
- Il fonctionne de manière fiable (ou alors c’est un bug du générateur, pas du projet)
- Le code généré ne respecte pas le code style du projet (donc checkstyle explose)
- La couverture du code généré par les tests n’est pas toujours intéressante
Si tout ces outils pouvaient prendre en compte l’annotation @Generated, ce serait génial.
Bonus : l’annotation @Generated permet de spécifier l’outil responsable de la génération. Par exemple @Generated(value= »axis2″). On pourrait donc finement configurer le code à ignorer en fonction du générateur.
Bonus 2 : l’annotation @Generated peut se positionner non seulement sur une classe, mais également sur une méthode, un attribut, … Donc on pourrait au sein d’une même classe distinguer le code généré du code manuel !!! Chose qui n’est actuellement pas possible de configurer dans les outils que j’utilise (en général on exclut un package complet de l’analyse).
A suivre…
Bonnes suggestions, par contre pour ajouter une petite note l’outil de génération de code EMF d’eclipse gère très bien cette annotation.