Le pour

- Je suis auteur de mon code, je l’assume et je l’écris de manière professionnelle en pensant à ceux qui vont me lire. C’est une idée que partage Robert C. Martin.

The @author field of a Javadoc tells us who we are. We are authors. And one thing about authors is that they have readers. Indeed, authors are responsible for communicating well with their readers. The next time you write a line of code, remember you are an author, writing for readers who will judge your effort.

- Surtout dans l’open-source, cela permet de laisser une trace de son investissement. Voir de se faire un nom.
- Il peut contenir l’adresse d’une mailing-list, ce qui permet, lors d’une question sur une classe de contacter directement les personnes responsables.

Le contre

- DRY : don’t repeat yourself : l’information est déja présente dans le SCM (git, svn ..).
- Le code appartient à tous : le @author doit donc etre collectif.
- Si il ne contient que l’auteur initial, celui-ci ne vaut pas plus que les autres.
- évite la sacralisation d’un unique développeur
- Pose le problème de savoir quand on doit se rajouter dans la balise @author.

Je laisse à Emmanuel Bernard le tweet de la fin :

Merci à ‏Sébastien PRUNIER ‏ @sebprunier, Pierre TEMPLIER ‏ @ptemplier, Emmanuel LECHARNY, François Sarradin ‏ @fsarradin, Guillaume LOURS ‏ @guillaumelours, Jean-Laurent Morlhon ‏ @morlhon, Arnaud Héritier ‏ @aheritier , Sébastien Deleuze ‏ @sdeleuze , Yannick AMEUR ‏ @yannickameur , Robin Komiwes ‏ @robinkomiwes , Jollivet Christophe ‏ @jollivetc , Jérémy Sevellec ‏ @jsevellec, Julien Jakubowski ‏ @jak78 , Nicolas De loof ‏ @ndeloof, Nicolas François ‏ @nicofrancois , Francois Marot ‏ @FrancoisMarot , Jean Helou ‏ @jeanhelou, Benoît Dissert ‏ @bdissert , Olivier Jaquemet ‏ @OlivierJaquemet , Aline Paponaud ‏ @bootis , Benoît Dissert ‏ @bdissert , Nicolas Delsaux ‏ @riduidel et aux autres …