Discussion :

[stardeath]

...

mon avis c'est que set ne ment pas, tu proposes une valeur et celui à qui tu fais ta soumission vérifie, traite ta donnée et garde le résultat ou rejette ta valeur en t'engueulant rtfm si tu respecte pas ce qui est demandé en prérequis.
l'important c'est que le destinataire ne rompe pas son propre contrat lors d'un set, sinon c'est que l'auteur n'a pas fait son boulot de ne faire confiance à personne.

la mise en avant des données, c'est aussi se cacher qu'il n'y a pas que les services dans la vie, il faut aussi avoir de quoi les nourrir.

quant à défendre les mauvaises pratiques, ne pas ou mal documenter un composant logiciel est pour moi pire que de mal nommer une fonction ou deux.
dans le cas d'un mauvais nommage, un wrapper et hop le problème est réglé à moindre coût et à notre gout ; par contre une mauvaise ou l'absence de doc entraine un try and die jusqu'à comprendre le bon fonctionnement du composant. et là le coût est très élevé.

[koala01]

Pour moi, setX(Y) signifie : donner une valeur à X en fonction de Y

Tout le code que j'ai pu croiser avec des set prenait plutôt le sens de assigner à X la valeur indiquée par Y (en utilisant ton propre exemple)

C'est peut etre une assertion honteusement erronée, mais si tu poses à brûle pourpoint la question aux développeurs, tu auras vraisemblablement une réponse souvent similaire

Quand on pense que le simple fait de donner un nom qui correspond au résultat observable permet de faciliter la vie de tout le monde, il est un peu dommage de ne pas le faire, non

[oodini]

- mise des données en avant au lieu des services, et autre viol de la loi de Déméter
- et nom menteur car il ne correspond pas à ce qu'il se passe réellement

- Les services, c'est pour les interfaces publiques. Je ne vois pas en quoi un setter serait gênant pour une méthode privée.

- Je ne vois pas pourquoi donner une valeur à quelque chose ne pourrait pas être un service. Koala, dans sa doc, cite plusieurs cas où cela a un sens.

- Si vous êtes aussi sensibles au mensonge, c'est peut-être parce que vous donnez un sens trop restrictif au mot set.

[dragonjoker59]

Dans l'optique du Read The Fucking Source Code, je mets généralement mes mutateurs de type "SetXXX" en inline, extrêmement souvent sur une seule ligne, dans le .h (pas dans un .inl, un seul fichier à ouvrir).

Ca reste du "Set" donc affectation à la valeur fournie seulement, sinon je ne mets pas "Set".

De plus en plus je documente mes mutateurs, même de type Set, sait-on jamais, en plus ça fait plus joli dans une doc Doxygen qu'une fonction membre non documentée (je sais, c'est moche comme argument ).

[oodini]

Tout le code que j'ai pu croiser avec des set prenait plutôt le sens de assigner à X la valeur indiquée par Y (en utilisant ton propre exemple)

La majorité du code que j'ai croisé également. Mais pour une raison simple : c'est le moyen de faire la nique à l'encapsulation à moindres frais.

C'est peut-être une assertion honteusement erronée, mais si tu poses à brûle pourpoint la question aux développeurs, tu auras vraisemblablement une réponse souvent similaire

Les développeurs et les "créas" utilisent souvent "fonte" au lieu de "police" et inversement, les commerçants "achalandé" pour dire "bien approvisionné"... Ce n'est pas pour ça qu'ils ont raison. En fait, peu de gens s'interrogent sur le vrais sens des mots, y compris dans leur propre métier et leur propre langue.

Quand on pense que le simple fait de donner un nom qui correspond au résultat observable permet de faciliter la vie de tout le monde, il est un peu dommage de ne pas le faire, non

A condition qu'on me donne un mot équivalent pour faire ce qui correspond à la définition que j'ai donnée.

[oodini]

(je sais, c'est moche comme argument ).

C'est un premier pas vers la noblesse.

[ternel]

Pour moi, setX(Y) signifie : donner une valeur à X en fonction de Y.
Le cas où X reçoit la valeur de Y est un cas particulier, qu'on pourrait, pour lever toute ambigüité, nommer ce dernier cas setXAs().

Surtout, éviter setTo (= prise de bec) !

Fol que tu es !

Set est un mot anglais signifie fixer, définir.
J'ose espérer que "I set your salary to 100k€" signifiera bien que "your salary is now 100k€".
Autrement dit, pour la seule raison que j'ai appelé la fonction linguistique "oodini.setSalary(100k€)", j'espère bien que "oodini.getSalary()==100k€".
Après, libre à l'implémentation du sieur oodini de mentir, pour me dire que son salaire est bien celui que je lui ai assigné.

(je sais pas, je me sentais généreux, sur ce coup-ci)

L'idée, c'est que si je décide de fixer une valeur, par le biais de l'interface mise à ma disposition, et que je demande cette valeur, j'obtient bien ce que j'y ai mis (pour peu que la documentation n'indique pas une conversion explicite).

[Luc Hermitte]

IIRC, À propos de contrat, c'est au client de le vérifier et balancer l'exception. Un non respect dans le code appelé, de l'undefined-behaviour est tolérable quand on reprend les articles/livre fondateurs.

Sinon,
- Un setter en privé, ne mérite pas vraiment que l'on s'attarde sur le sujet. Si violation de nom il y a, tant pis pour le développeur de la classe.
- Pour le service de taper dans des données, oui il arrive que cela soit valable. Mais majoritairement, c'est du mauvais design.
- Sommes-nous trop restrictifs pour le sens de set? Ou conscients qu'il existe quantité de verbes qui seront bien plus adaptés à chaque cas ?



Quant à aller bidouiller les données, j'insiste, c'est ça la mauvaise pratique. Un code que j'ai audité il y a peu avait une structure avec un champ pointeur public, un destructeur qui faisait le delete[], et des codes clients qui allaient modifier comme des sauvages le pointeur sans regarder ce qu'il y avait dedans avant. Plus une copie non gérée.
Certes ils aurait pu patcher avec un setBuffer(char *) qui fait le RAZ qui va bien. Et pourtant vous savez tous que cela eut été faux (car le delete[] et le new[] peuvent alors être incompatibles).
La solution que j'ai préconisée, un respect de la LoD avec un resize(size_t), ou un setData(char const*, size_t) -- et là je vois avec le recul que copyData() eut été une solution bien meilleure. (et un std::vector en interne)

[koala01]

mon avis c'est que set ne ment pas, tu proposes une valeur et celui à qui tu fais ta soumission vérifie, traite ta donnée et garde le résultat ou rejette ta valeur en t'engueulant rtfm si tu respecte pas ce qui est demandé en prérequis.
l'important c'est que le destinataire ne rompe pas son propre contrat lors d'un set, sinon c'est que l'auteur n'a pas fait son boulot de ne faire confiance à personne.

C'est là que l'on n'est visiblement pas d'accord.

Le fait est que de nombreux codes que l'on croise ne font effectivement qu'assigner à un membre dont le nom est donné par le mutateur (au mépris de LoD et de ISP !!!!) la valeur fournie en paramètre, et que cela "doit être ainsi" dans "l'inconscient collectif".

On pourrait, éventuellement, considérer qu'un mutateur qui ne fait effectivement que cela "Et tant pis pour toi si la valeur indiquée est non conforme" ne ment effectivement pas à l'utilisateur, mais on se rend compte qu'il contrevient (comme je viens de le rappeler) à au moins une loi et un principe qui correspond à un des piliers de la programmation orientée objets, sans oublier la joie que cela va t'occasionner au débuggage

A coté de cela, tu as quelques mutateurs qui vont vérifier la cohérence, faire le café et embrasser la mariée.

A partir du moment où "l'inconscient collectif" estime qu'un mutateur a un comportement qui ne correspond pas à ce que fait le tien, il y a discordance entre ce que l'utilisateur comprend de ce qu'est sensée faire ta fonction et ce qu'elle fait effectivement, et l'on peut donc dire que ta fonction ment à l'utilisateur

la mise en avant des données, c'est aussi se cacher qu'il n'y a pas que les services dans la vie,

Non, il y a aussi des comportements.

La distinction entre le comportement et le service est qu'un service est d'office publique (accessible depuis partout) alors qu'un comportement peut ne pas être publique et n'être qu'une partie "interne" d'un service rendu

il faut aussi avoir de quoi les nourrir.

Ben quoi, on sait les nourrir sans problème:

• Avec membres de l'objet, pour commencer
• En leur fournissant des arguments ensuite

Mais:

1. Crois tu vraiment améliorer l'encapsulation en plaçant la donnée en accessibilité privée et en fournissant un mutateur
2. Ne crois tu pas que tu pourrais fournir un nom qui indiquera clairement le résultat que tu vas obtenir plutôt qu'un setXXX qui est la solution de fainéantise

quant à défendre les mauvaises pratiques, ne pas ou mal documenter un composant logiciel est pour moi pire que de mal nommer une fonction ou deux.

Je n'en suis pas persuadé.

D'abord, parce que le premier réflexe de l'utilisateur n'est pas d'aller voir la doc, mais de se baser sur le nom des fonctions, en estimant "qu'elle fait ce qu'on attend d'elle" et en se basant sur sa propre lecture (du nom de la fonction) pour "déduire" ce qu'elle est sensée faire

Ensuite, bien que je ne partage pas ce point de vue, l'argument du "mieux vaut pas de commentaire qu'un commentaire non mis à jour" a malgré tout des accents de vérités.

Si tu ne peux pas demander au développeur de choisir des noms de fonctions explicites, n'essaye pas de lui demander de tenir un commentaire à jour

dans le cas d'un mauvais nommage, un wrapper et hop le problème est réglé à moindre coût et à notre gout ;

C'est parfois pas aussi simple

par contre une mauvaise ou l'absence de doc entraine un try and die jusqu'à comprendre le bon fonctionnement du composant. et là le coût est très élevé.

Que tu pourrais éviter si ta fonction portait un nom cohérent avec ce qui est fait

[oodini]

Set est un mot anglais signifie fixer, définir.

Nous sommes d'accord.

J'ose espérer que "I set your salary to 100k€" signifiera bien que "your salary is now 100k€".

Tout à fait.

Autrement dit, pour la seule raison que j'ai appelé la fonction linguistique "oodini.setSalary(100k€)", j'espère bien que "oodini.getSalary()==100k€".

Eh non, tu fais erreur : tu as, dans ce codage un peu trop conforme aux us et coutumes, oublié la préposition to pour conserver le sens introduit ci-dessus. La présence de ce mot n'est pas anodine, et a un rôle bien précis.

Après, libre à l'implémentation du sieur oodini de mentir, pour me dire que son salaire est bien celui que je lui ai assigné.

Je te laisse la liberté de jouer avec la langue.

(je sais pas, je me sentais généreux, sur ce coup-ci)

Ce contentement t'a porté préjudice.

L'idée, c'est que si je décide de fixer une valeur

Il faut utiliser une fonction setTo(), ou setAs(), mais pas une fonction set().

par le biais de l'interface mise à ma disposition, et que je demande cette valeur

...avec une fonction mal nommée

j'obtiens bien ce que j'y ai mis (pour peu que la documentation n'indique pas une conversion explicite).

Un livre de grammaire peut également être utile.

En ce qui me concerne, je suis disposé à me conformer aux usages de la majorité, mais vous ne me ferez pas admettre que la majorité a raison.

[koala01]

La majorité du code que j'ai croisé également. Mais pour une raison simple : c'est le moyen de faire la nique à l'encapsulation à moindres frais.

Ah, commencerait on à converger

Et, sincèrement, tu ne trouves pas embêtant de "faire la nique à l'encapsulation", pour reprendre tes propres termes

Les développeurs et les "créas" utilisent souvent "fonte" au lieu de "police" et inversement, les commerçants "achalandé" pour dire "bien approvisionné"... Ce n'est pas pour ça qu'ils ont raison. En fait, peu de gens s'interrogent sur le vrais sens des mots, y compris dans leur propre métier et leur propre langue.

Effectivement, mais le débat ne porte ni sur l'utilisation de fonte ni sur celle de achalandé

A condition qu'on me donne un mot équivalent pour faire ce qui correspond à la définition que j'ai donnée.

Et un nègre (au sens littéraire du terme, hein ) pour écrire ton code, et une secrétaire pour faire ta paperasse en prime

Ce que l'on te propose, et c'est déjà pas si mal , c'est d'essayer de trouver le terme qui convient

[oodini]

Ce que l'on te propose, et c'est déjà pas si mal , c'est d'essayer de trouver le terme qui convient

Ce que je propose est mieux (mais utopique) : éradiquer un terme qui ne convient pas.

[koala01]

En ce qui me concerne, je suis disposé à me conformer aux usages de la majorité, mais vous ne me ferez pas admettre que la majorité a raison.

Encore faut il voir de quelle majorité tu parles

Nous n'essayons très certainement pas de te convaincre que la majorité des développeurs (celle qui a fait la base de code existant) a raison, car il est clair pour nous qu'elle a tord

Par contre, si tu parles de la majorité des intervenants à cette discussion, soit, mais montre nous alors que nous faisons fausse route et que notre raisonnement est incorrect

Ce que je propose est mieux (mais utopique) : éradiquer un terme qui ne convient pas.

Ca, c'est le but ultime, on commence par te donner les outils pour y arriver

[stardeath]

Que tu pourrais éviter si ta fonction portait un nom cohérent avec ce qui est fait

si on part du principe que le développeur est mauvais et fainéant, il ne va surement pas non plus mettre un nom de méthode constructif XD

[white_tentacle]

IIRC, À propos de contrat, c'est au client de le vérifier et balancer l'exception. Un non respect dans le code appelé, de l'undefined-behaviour est tolérable quand on reprend les articles/livre fondateurs.

yep. C’est aussi ce que j’ai appris.

La solution que j'ai préconisée, un respect de la LoD avec un resize(size_t), ou un setData(char const*, size_t) -- et là je vois avec le recul que copyData() eut été une solution bien meilleure. (et un std::vector en interne)

C’est un cas qu’on avait oublié d’évoquer, tiens, le mutateur qui prend un pointeur. Quid de l’ownership ? Avec copyData, le sens est beaucoup plus clair

[oodini]

Nous n'essayons très certainement pas de te convaincre que la majorité des développeurs (celle qui a fait la base de code existant) a raison, car il est clair pour nous qu'elle a tort

Bah... Dans 10 ou 20 ans, elle aura peut-être raison.
Les paradigmes de programmation sont mouvants.

Par contre, si tu parles de la majorité des intervenants à cette discussion, soit, mais montre nous alors que nous faisons fausse route et que notre raisonnement est incorrect

Mon propos est simple :[*] le terme set est mal compris (mon diagnostic)[*] de là, il est souvent mal utilisé[*] de là, on lui reproche mille maux, souvent de manière injuste

Ce qui me frappe le plus, ce sont les dogmes : "il ne faut jamais faire ceci ou cela", "il ne faut pas violer telle règle ou telle règle".

Il faut bien comprendre que les règles sont faites pour se prémunir des mésusages, mais il faut garder son discernement, avoir un sens critique sur la situation, et s'adapter quand cela est nécessaire.

OUI, parfois on peut utiliser les pointeurs et des fonctions du C.
OUI, parfois on peut utiliser un dynamic_cast ou un goto.
OUI, on peut avoir à coder des choses sales pour que le code soit efficace, tout en sachant qu'il ne sera pas maintenable.

[koala01]

si on part du principe que le développeur est mauvais et fainéant, il ne va surement pas non plus mettre un nom de méthode constructif XD

Si si tu lui interdit l'utilisation de "set" dans les règles de codage

Plus sérieusement, le mauvais développeur acceptera sans doute plus facilement la contrainte de "veux tu bien changer ce nom qui ne veut rien dire" que n'importe quelle contrainte portant sur des aspects qui ne lui semblent pas primordiaux ou risquant, à ses yeux du moins, de poser d'avantage de problèmes que cela n'apporte de solutions (comme un cartouche pour toute fonction déclarée "qui risque de ne pas être mis à jour").

Bien sur, un sérieux "écrémage" ne serait peut etre pas du luxe dans la profession, mais on risque d'attendre encore une ou deux générations avant qu'il ne survienne

[koala01]

Mon propos est simple :[*] le terme set est mal compris (mon diagnostic)[*] de là, il est souvent mal utilisé[*] de là, on lui reproche mille maux, souvent de manière injuste

Tu oublies un aspect primordial, sur lequel tu as même fini par tomber d'accord

Oui, le terme est globalement mal compris, oui il est donc (oserais-je dire forcément allez, j'ose ) mal utilisé et oui on lui reproche mille maux.

Mais non, ce n'est pas pas injustifié: notre justification se trouve dans la base de code existante

Ce qui me frappe le plus, ce sont les dogmes : "il ne faut jamais faire ceci ou cela", "il ne faut pas violer telle règle ou telle règle".

Il ne me semble pourtant pas que quiconque ait été à se point dogmatique dans la discussion.

Bien sur, certaines raisons invoquées on trait à des principes reconnus, mais cela me semble normal, dans le sens où il y a effectivement lieu de mettre une pratique "habituelle" en relation avec des principes globalement admis, non :quesiton:

Il faut bien comprendre que les règles sont faites pour se prémunir des mésusages, mais il faut garder son discernement, avoir un sens critique sur la situation, et s'adapter quand cela est nécessaire.

Oui, à un bémol près:

S'il faut garder le sens critique au niveau de l'implémentation, la conception en elle-même a très fortement intérêt à être sans faille.

Le meilleur moyen d'avoir une conception sans faille est, quoi qu'on en dise, de ne prendre aucune liberté vis à vis des lois, principes et concepts que l'on doit appliquer.

Ou plutôt: tu auras tout à gagner à ne prendre aucune liberté sur le sujet, car cela ne fait qu'armer le pistolet qui finira par te tirer, tot ou tard, une balle dans le pied. La question n'étant pas de savoir SI il va tirer, mais QUAND, et avec quelles conséquence

OUI, parfois on peut utiliser les pointeurs et des fonctions du C.
OUI, parfois on peut utiliser un dynamic_cast ou un goto.
OUI, on peut avoir à coder des choses sales pour que le code soit efficace, tout en sachant qu'il ne sera pas maintenable.

Toutes ces discussions ont déjà eu lieu, et, si tu fais une recherche sur le forum, tu te rendras compte que nous sommes tous d'accord avec cela, à un bémol près:

Cela doit se faire dans des circonstances dans lesquelles cela représente clairement la moins mauvaise solution (à défaut de représenter la meilleure ), c'est à dire être clairement documenté et justifié

Cela implique aussi que les cas où nous devrons le faire de la sorte se doivent de rester exceptionnels

Mais, cela signifie donc qu'il faut de très bonnes raisons, imposée par des situations particulières pour décider de faire de la sorte.

Au final, il vaut mieux avoir un discours proche de "a priori, faite de la bonne manière (celle qui n'utilise ni pointeur ni fonction du C, celle qui évite les transtypages, celle qui n'utilise pas goto) et si (et uniquement si) vous n'en sortez réellement pas de la sorte, envisager l'alternative crado".

Ne crois tu pas que ce genre de discours est préférable à la bénédiction pure et simple quant au fait de recourir à une solution "crade"

[stardeath]

Si si tu lui interdit l'utilisation de "set" dans les règles de codage

le set a quand même l'avantage d'exposer l'unicité de la cible, je ne connais pas de meilleur mot "clé" pour ça.

Plus sérieusement, le mauvais développeur...

effectivement ça lui donnera moins de boulot, mais si je dois demander à l'auteur de changer quelque chose, c'est que je devrais faire confiance à ce qu'il a écrit, je préfère dans ce cas qu'il me documente sa chose avec le max de précision plutôt que de compter sur un choix de nommage.

avec une vraie doc, je pourrai démontrer que son code ne respecte pas le contrat qu'il a édicté, alors qu'un changement de nom sera toujours propice aux "mais tu n'as pas compris comment il fallait s'en servir".
la responsabilité devant revenir à l'auteur et non pas au client en cas de non respect d'un quelconque contrat, selon moi.

[koala01]

effectivement ça lui donnera moins de boulot, mais si je dois demander à l'auteur de changer quelque chose, c'est que je devrais faire confiance à ce qu'il a écrit, je préfère dans ce cas qu'il me documente sa chose avec le max de précision plutôt que de compter sur un choix de nommage.

avec une vraie doc, je pourrai démontrer que son code ne respecte pas le contrat qu'il a édicté, alors qu'un changement de nom sera toujours propice aux "mais tu n'as pas compris comment il fallait s'en servir".
la responsabilité devant revenir à l'auteur et non pas au client en cas de non respect d'un quelconque contrat, selon moi.

A priori, il faut quand même respecter OCP aussi, dont on n'a pas encore parlé

L'idée est donc que l'on devrait nommer la fonction sur base du service qu'elle rend au moment où on l'écrit (ou lors de la revue de code qui précède un gros commit ).

Si, pour une raison ou une autre, il apparait comme nécessaire, après une évolution de renommer une fonction, c'est qu'on n'a, de toute évidence, "loupé quelque chose" en terme de respect du principe "ouvert fermé"

Si tu préfères le point de vue opposé, on peut dire que, a priori, le nom de fonction sera relativement stable, une fois qu'il aura été choisi avec soin.

La nécessité de renommer une fonction n'apparait donc que dans quelques cas bien particulier, et est généralement mauvais signe, non