Discussion :

[Luc Hermitte]

Pour doxygen.
Beaucoup de tags sont totalement inutiles et alourdissent une doc qui est déjà bien assez illisible => ouste les @class, @fn, @enum, @type, etc. Et même @brief je l'ai viré pour exploiter à la place l'option auto-brief.
Au sujet de @param et @return, je vous invite à regarder la doc générée, vous verrez que toutes les décorations qui font bien dans votre EDI qui ne colore pas correctement la doc doxygen sont de trop dans les résultats (=> pas de ':', '-', '\b', ...)
Koala a listé les principales choses à remplir dans des commentaires doxygen, et je rajouterai les groupes. Ils permettent d'organiser la doc en unités cohérentes, et de fait de la rendre exploitable.

Je suis également à 100% derrière Koala au sujet des accesseurs et mutateurs. Ce ne sont pas des outils d'encapsulation, mais de décapsulation. Au final, ils sont là pour violer la loi de Déméter.
Quant à l'histoire de maintenabilité.... c'est du pipeau! Commencez par réfléchir en services, après vous verrez combien de fois le contenu des soit disant setter/getter change véritablement.
Et puis, je vous renvoie aussi à la prose d'Emmanuel Deloget à ce sujet. La question du nommage qui ne correspond pas à ce qui est fait est également très importante: set != checkThenSetIfOK.

PS: @LinuxUser tes getters ne sont pas const-corrects.

[white_tentacle]

C’est bizarre ce débat perpétuel sur les getter/setter alors que ce concept même devrait être ultra-limité :
- soit mon objet est juste un conteneur de données, et dans ce cas tout est public
- soit c’est un objet métier, et dans ce cas, le concept de getter/setter est une très mauvaise abstraction (cf le message de koala)

Sinon, personnellement je mets les commentaires doxygen dans les headers, et par contre, je commente le code c++ à toute «*siouxerie*», chose «*non-intuitive*», ou simplement un détail nécessaire (par exemple, dire qu’on utilise tel algorithme plutôt qu’un autre, notifier la fin d’une section critique…).

[r0d]

C’est bizarre ce débat perpétuel sur les getter/setter

Je pense que c'est parce que c'est une notion qui est différente selon les langages. Par exemple, en c#, on ne parle pas de variables membres, mais de propriétés d'une classe, et ces propriétés sont "automatiquement" exposées (le code de leurs accesseurs/mutateurs sont générés automatiquement lors de leur création). En java il y a une mécanique du même type si je me souviens bien.
Du coup ça génère des ambiguités.

Il y a aussi le fait que ce n'est jamais tout noir ni tout blanc. Certains considèrent que begin() et end() (fonctions qui retournent des itérateurs) sont des accesseurs, par exemple.

[Luc Hermitte]

C'est perpétuel car de façon directe ou indirecte, c'est ce qui est enseigné. Pour trop, encapsulation veut dire ne pas exposer directement les données et donc les rendre accessible via une paire de fonctions. Et donc régulièrement on corrige ces mauvais réflexes.

[koala01]

Il y a aussi le fait que ce n'est jamais tout noir ni tout blanc. Certains considèrent que begin() et end() (fonctions qui retournent des itérateurs) sont des accesseurs, par exemple.

...parce qu'ils correspondent, effectivement, à une notion de service attendus de la part des classes qui les exposent.

Nous les trouvons, généralement, dans le cas de collections d'objets / de données, et il faut bien être en mesure de les récupérer, vu que cela fait partie intégrante du rôle d'un conteneur

[koala01]

Koala a listé les principales choses à remplir dans des commentaires doxygen, et je rajouterai les groupes. Ils permettent d'organiser la doc en unités cohérentes, et de fait de la rendre exploitable.

Oui, je les avais oubliés, tiens... Et pourtant, je les utilise de manière systématique (enfin, quand le projet est prévu pour )