Comment nommer une variable lorsque le mot est à la fois un nom et un verbe
J'ai rencontré un problème de cas d'angle avec les conseils généraux de:
- noms pour les variables
- verbes pour fonctions
Plus précisément, j'ai un cas où le mot est ambigu - il peut être soit un verbe ou un nom. Et dans certains cas, lorsque nous discutons de l'application, elle sera utilisée les deux façons dans la même phrase.
Mon intention est de m'assurer que le programme restera lisible pour les futurs développeurs ainsi que moi-même lorsque je reviendrai sur des sections de code des mois plus tard.
Un des exemples est avec un battery. Un battery a un charge et vous pouvez également charge() une batterie.
Je pense qu'avoir à la fois Battery.Charge Et Battery.Charge(value) sera déroutant pour les futurs développeurs.
Ma solution actuelle consiste à simplement choisir un mot différent pour l'un ou les deux de ces cas (la variable et la fonction). Mon problème avec cette approche est que la variable et la fonction de l'objet Battery pour charge ne seront pas alignées avec les discussions de conception impliquant le Battery.
Ma question est de savoir s'il existe une autre/meilleure façon de gérer ce conflit dans la convention de dénomination?
Quelques lectures supplémentaires sur le sujet. Aucun n'a vraiment abordé le détail de ma question.
Dans des situations similaires, j'essaie de trouver des synonymes. Dans ce cas, j'utiliserais "recharge" pour le verbe. Le "re" est légèrement redondant, mais le sens est clair. L'utilisation de la "charge" simple pour la charge restante de la batterie est ambiguë car elle ne spécifie aucune unité physique. Je préférerais "availableAmpHours", "hoursUntilRecharge" ou quelque chose de similaire. Les unités dépendent de ce qui convient à l'application.
Ma préférence personnelle est d'utiliser les verbes uniquement pour les fonctions qui changent d'état. J'utilise des noms pour des fonctions non mutantes. Je suppose que cela dépend de votre point de vue. Au niveau de la machine, les fonctions non mutantes font quelque chose, mais au niveau du modèle, elles ne le font pas.
Il suffit de lancer cela, mais peut-être que la solution pour cette instance d'ambiguïté de nommage est de supprimer complètement cette fonctionnalité de la batterie. Je n'ai jamais vu de batterie auto-chargée et il serait plus logique pour moi d'avoir une classe BatteryCharger. Cela aiderait à dissocier vos préoccupations et à rendre l'action plus explicite.
battery.Charge(50) vs batteryCharger.Charge(battery, 50)
Pour moi, le deuxième formulaire est beaucoup plus compréhensible et conserve tout votre code de "charge" en un seul endroit plutôt que de le saupoudrer dans toutes vos classes de batterie.
Évitez les doubles significations
Vous avez délibérément choisi un mot qui a plus d'un sens, et cette première décision est le problème. Il y a une tonne de mots qui posent problème aux programmeurs. Un autre exemple serait phone. Vous pouvez phone quelqu'un, ou vous pourriez avoir un phone dans votre poche.
Utiliser les Getters et Setters
La dénomination standard pour la plupart des objets est les méthodes getters/settings pour les propriétés.
Battery.Charge // would be a property
Battery.setCharge(value) // would set the property
Battery.getCharge() // would get the property
Les propriétés sont des états et non des noms
Je pense que vous vous trompez en classant les propriétés des objets comme des noms, et les variables pourraient également être considérées comme des états. Ce sont des États pertinents pour l'étendue locale de leur existence.
Vous pouvez décrire la valeur qu'ils détiennent en tant que nom, mais je ne suis pas sûr que ce soit vrai dans tous les cas.
Dans OOP les propriétés des objets de terminologie décrivent l'état de cet objet. Dans votre cas, le Battery est un objet, et c'est Charge est un état. être une propriété de l'objet, mais cela dépend du contexte de la façon dont il est utilisé.
Si vous devez être en mesure de Charge la batterie, et aussi savoir ce que c'est Charge actuel, alors vous avez un problème.
Utilisation de Scope pour appliquer le contexte
Le contexte est ce qui clarifiera le sens d'un mot que vous souhaitez transmettre à une méthode ou à une propriété. La portée définit l'accessibilité d'une propriété/méthode depuis l'extérieur de l'objet.
Batter._charge // a hidden private property
Battery.setCharge(value) // would set the private property
Battery.getCharge() // would get the private property
Battery.Charge() // would perform the Charge action
Les méthodes sont des verbes
Vous pouvez décrire la méthode d'un objet comme un verbe, mais l'action Word est mieux adaptée. Dans la terminologie OOP, vous effectuez des actions sur les objets à l'aide de leurs méthodes. C'est une mauvaise forme de modifier la propriété d'un objet de l'extérieur de l'objet. Il est préférable d'appeler une méthode qui effectue les actions requises qui provoquent son état à changement.
Le mot Charge est un verbe, mais c'est aussi un substantif. Lorsqu'il est utilisé pour appeler la méthode d'une action, il devient clair que le verbe est utilisé Battery.Charge(....).
Mais, le contexte est très important. Bien que le mot Charge() soit un verbe, il n'est pas aussi significatif que startCharging().
Les méthodes valides pour Battery peuvent inclure Charging, Discharging, setCharge, getCharge, hasCharge, Discharge et Charged.
Les méthodes simples d'un mot n'énoncent souvent pas clairement leurs actions, mais il y a des cas comme open et close où peu d'explications sont nécessaires.
Il n'y a donc pas vraiment de réponse correcte quant à la façon de nommer ces types de propriétés/méthodes. Sauf que vous devez utiliser judicieusement les techniques ci-dessus pour éviter toute confusion.
Ajoutez-leur des verbes qui en feront un verbe ou un substantif.
Battery.doCharge()
Battery.getCharge()
Pour le cas du verbe, je pense que Charge est OK. Pour le cas du nom, getCurrentChargeLevel fonctionnerait-il pour vous?
Dans la plupart des cas, l'ajout d'un verbe aidant, d'un adverbe ou d'un adjectif est assez bon pour les distinguer et peut réellement aider à la compréhension. Avec votre cas de Charge et Charge () sur une batterie, DeltaCharge () pourrait montrer que c'est une fonction qui peut gérer la charge ou la décharge.
Delta (dans les cas où il y a un changement mais ambigu) est un modificateur que j'utilise et recommande aux autres tout le temps pour transmettre un changement d'état (même si le verbe est semi-évident).
La notation hongroise à la rescousse. Vous pouvez avoir intCharge et fcnCharge(value), évitant ainsi la confusion et n'ajoutant pas un nom long fou quand trois lettres fonctionneront très bien.
Ou vous pouvez simplement utiliser le même nom et laisser le IDE le gérer. Créer un nom plus long ou différent peut être tout aussi déroutant à long terme de toute façon.