Convention de nommage pour les getters/setters en Java

Conformément à JavaBeans spécification de l'API à partir de 1997
il devrait être comme Thomas Einwaller décrit.

private int xIndex;
public int getxIndex() { return xIndex; }
public void setxIndex(int xIndex) { this.xIndex = xIndex; }

C'est malheureux, getx et setx ne sont pas des mots, ce qui pour le cas rare où le code généré par l'Ide, aussi
reçoit un avertissement de la part de l'Ide. Ainsi, alors que ceci est conforme à la spécification Ejb, il viole la convention pour
la dénomination d'une méthode.
Dans les rares cas où ce serait de former un mot ou d'un sigle, il serait disinformative, par exemple, la méthodesetiMessage plus
probablement n'a rien à voir avec SETI.
À l'aide de la seule mesure valide de la qualité du code (WTFs par minute),
J'évalue que ce qui est mauvais code.

Tout se résume à cette phrase de la spécification Ejb:

Cependant à l'appui de l'utilisation occasionnelle de tous les majuscules des noms, nous vérifions si les deux premiers caractères du nom sont
les deux majuscules et si donc le laisser seul.

Exactement ce genre d'utilisation de tous les majuscules des noms de cette référence est claire pour moi. Les noms de champ devrait, selon
convention, camelcase. Il semble
pour moi que nous générons les noms de méthodes non conventionnelles pour soutenir non conventionnelles noms de champ tel que décidé par un
20 ans de document.

Il convient également de noter que, même si il semble être un soutien massif de la JavaBeans spécification des outils,
il n'est pas exclusivement utilisé. Par exemple. Kotlin ne reconnaîtra pas xIndex comme une propriété dans l'exemple ci-dessus. À l'inverse, l'
Kotlin propriété var xIndex = 0 entraînera dans les méthodes de Java getXIndex et setXIndex. Ce qui semble être un bug
selon le JetBrains soutien, mais je ne vois pas comment ils peuvent résoudre les que sans faire une modification de rupture.

Certains outils qui prend en charge la spécification Ejb n'a pas toujours fait, par exemple, Jackson
et Swagger Générateur De Code ont été patché pour se conformer à elle.
Même si IntelliJ générer les accesseurs en fonction de la spécification Ejb, le exemple
dans la documentation diffère. Probablement parce que les gens ne savent pas à propos de la norme et, naturellement, préfère la
méthode normale convention de nommage.

Alors, quand devrions-nous suivre les JavaBeans cahier des charges? Lorsque les noms de propriété doit être déduit par les accesseurs par les outils qui
s'appuyer sur cette norme, on peut vouloir utiliser. Par exemple, Jackson va s'appuyer
sur la propriété xIndex accessibles par getxIndex et setxIndex méthodes que si nous utilisons les annotations.

Quand doit-on éviter cette norme? Par ma recommandation: Lorsque le code doit être lu et compris par les humains.
En raison de ne pas utiliser la bonne chameau boîtier lors du nommage des méthodes est disinformative.

Si j'aurais à ma façon, nous aurions utilisation normale des conventions de nommage, c'est à dire getXIndex et setXIndex. Mais, compte tenu de l'état
des choses, la meilleure solution que je vois est suggéré par @vaxquis:

Nom de votre domaine "indexX" ou quoi que ce soit, votre problème est résolu... ne pas compliquer les choses - même si setxIndex
est la bonne façon pour les Haricots, avoir méthode nommée setxIndex augmente le WTF facteur du code sans vous donner
quelque chose en retour.

Des commentaires concernant la spécification Ejb doit, selon la spécification elle-même, être envoyé à
[email protected].

OriginalL'auteur Love

Méthodes doivent être des verbes, en majuscules et en minuscules avec la première lettre en minuscules avec la première lettre de chaque mot en majuscule.

OriginalL'auteur ayush

De l'ide Eclipse génère automatiquement les setters et getters:

getxIndex()
setxIndex(int value)

Qui est conforme à la spécification de l'API java beans.

OriginalL'auteur Bipin Thakur