Nommage d'une méthode : que pensez-vous qu'elle retourne au regard de son nom ?

[Sephi-Chan]

Le but est effectivement de montrer à la personne qu'un bon nommage est important, que ça évite même d'avoir à écrire des commentaires inutiles ainsi qu'une bonne dose d'ambiguïté.

Après, la démonstration concernant l'ambiguité de la langue ne fait qu'enfoncer le clou, mais ce n'était pas le but premier.

Selon l'auteur, cette méthode retourne un tableau des planètes possédées par l'équipe. Un bon nommage français (sic) aurait été getPlanetesControllees. Le pluriel implique une collection et le participe passé lève l'ambiguité sur le terme "contrôle".

[niahoo]

arf j'arrive après la bataille.

J'aurais dit comme Ter Rowan

[Ter Rowan]

Get : méthode d'un objet retournant un attribut unique (...). Cela ne peut pas être un tableau de valeur/objet. Il est forcément unique.

Arius es tu sûr de cela ? J'ai demandé à mes experts / architectes, pour eux, il ,'y a aucun problème sur le fait de retourner un tableau de données pour une méthode commençant par Get

[Arius Vistoon]

je suis absolument sur de cela...je suis expert en architecture, entre autre.

Cependant, une bon "nommage" n'est valide qu'au sein d'une culture spécifique. ainsi si chez tes experts, tout le monde a l'habitude de l'utiliser autrement, c'est tout aussi valable..le but c'est que cela soit intuitif pour les personnes concernées. Hors les personnes pensent/réfléchissent différemment suivant la culture qu'elles ont.

[Sephi-Chan]

Je ne suis pas convaincu à propos des getters, tous les frameworks de persistance Java/Dotnet utilisent des getters qui retournent des collections, genre getEmployees().

Ruby simplifie ça avec team.owned_planets ! :p

[Arius Vistoon]

Je ne suis pas convaincu à propos des getters, tous les frameworks de persistance Java/Dotnet utilisent des getters qui retournent des collections, genre getEmployees().

Ruby simplifie ça avec team.owned_planets ! :p

Ce n'est pas parce que tout le monde le fait que c'est bon
Mais encore une fois, le but recherché (intuitivité de ce que fait la fonction) dépends de la culture du publique cible. Un publique chinois par exemple (je cite cette exemple car j'ai vecut en chine), ne trouveras pas le getEmpoyees() pertinent, d'ailleurs il ne le comprendra même pas...il n'y a pas de mots au pluriel en Chine ! donc pour lui getEmployees() sera la même chose que getEmploye() mais avec une faute d'orthographe iffle
J'ai pris l'exemple de culture différente au niveau géographique pour tirer un peu le trait, mais c'est tout aussi valable au sein de personnes habituées a tel langage "contre" celles habituées à tel autre langage ou les employés de tel entreprise "contre "ceux de tel autre entreprise. Et ce que nous appelons normes n'est en fait qu'une norme parmi un groupe d'individus (plus ou moins définie).

Pour ma part (et tous ceux que j'ai formé), je préconise l'emploi de "listEmployee()"..avec ou non la faute d'orthographe pour le pluriel suivant la sensibilité de mon publique à ce sujet . D'ailleur si on regarde bien, quand il y a un get, il y a set, hors dans le cas d'une liste, il y a rarement de set (dans mes cas de figure jamais vus que je les détermine en amont, via mes schémas UML).

[Sephi-Chan]

Tu as raison : c'est parcequ'une solution est bonne que beaucoup l'utilisent. D'où la création de design patterns. Après, tu parles de culture mais si tes chinois codent en anglais, il faut s'adapter. C'est l'avantage d'une langue unique dans les développements.

Mais le plus important, c'est la cohérence.

[Ter Rowan]

merci pour les précisions

[Arius Vistoon]

Après, tu parles de culture mais si tes chinois codent en anglais, il faut s'adapter. C'est l'avantage d'une langue unique dans les développements.

nan :roi: les chinois (que j'ai eu l'occasion de rencontrer, je ne cherche pas à généraliser, quoique...) ne comprennent pas l'anglais, il code suivant ce qu'on leur a dit (dans le meilleur des cas) qu'il fasse coder. Hors comme ils ne connaissent pas les autres langages et que ceux -ci sont totalement illogique (d'ailleurs pour moi aussi) à leur yeux, le mieux est d'éviter de perdre en productivité et donc de mettre des mots totalement différent (et donc proche de leur langue) pour etre sur qu'il n'oublieront pas le "s" qui pour eux est une faute d'orthographe et preuve de l'incohérence de leur interlocuteur..et donc de crédibilité et donc...de respect. Bref, plus il y a de barrière, plus il y a d'erreur et de laxisme dans le travail (chinois ou non)

Mais le plus important, c'est la cohérence.

et l'intuitivité pour les personnes concernées (pour éviter de perdre en productivité)

[Hideaki]

Il aurait utilisé Possédé au lieu de contrôlé cela aurait déjà levé un doute
Concernant le type de retour, on peut supposer que l'EDI travail à nous éclairer même si cela ne facilite pas la lecture.

Je supposais que c'était un débutant en partie à cause de $foo, si tu oublies à quoi correspond $foo, il est nécessaire de rechercher l'affectation de la variable vu que php n'est pas typé.