Publicité
+ Répondre à la discussion
Page 2 sur 2 PremièrePremière 12
Affichage des résultats 21 à 26 sur 26
  1. #21
    Expert Confirmé Sénior
    Avatar de Luc Hermitte
    Homme Profil pro Luc Hermitte
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    4 745
    Détails du profil
    Informations personnelles :
    Nom : Homme Luc Hermitte
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 4 745
    Points : 7 823
    Points
    7 823

    Par défaut

    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.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  2. #22
    Membre Expert
    Avatar de white_tentacle
    Inscrit en
    novembre 2008
    Messages
    1 292
    Détails du profil
    Informations forums :
    Inscription : novembre 2008
    Messages : 1 292
    Points : 1 999
    Points
    1 999

    Par défaut

    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…).

  3. #23
    r0d
    r0d est déconnecté
    Expert Confirmé Sénior

    Profil pro
    Inscrit en
    août 2004
    Messages
    4 098
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : août 2004
    Messages : 4 098
    Points : 5 752
    Points
    5 752

    Par défaut

    Citation Envoyé par white_tentacle Voir le message
    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.

  4. #24
    Expert Confirmé Sénior
    Avatar de Luc Hermitte
    Homme Profil pro Luc Hermitte
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    4 745
    Détails du profil
    Informations personnelles :
    Nom : Homme Luc Hermitte
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 4 745
    Points : 7 823
    Points
    7 823

    Par défaut

    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.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  5. #25
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 762
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 762
    Points : 17 281
    Points
    17 281

    Par défaut

    Citation Envoyé par r0d Voir le message
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  6. #26
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 762
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 762
    Points : 17 281
    Points
    17 281

    Par défaut

    Citation Envoyé par Luc Hermitte Voir le message
    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 )
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •