Je vois souvent du code qui inclut des fautes d'orthographe intentionnelles de mots courants qui, pour le meilleur ou pour le pire, sont devenus des mots réservés:
klass
ouclazz
pour la classe :Class clazz = ThisClass.class
kount
pour compter en SQL:count(*) AS kount
Personnellement, je trouve que cela diminue la lisibilité. Dans ma propre pratique, je n'ai pas trouvé trop de cas où un meilleur nom n'aurait pas pu être utilisé - itemClass
ou recordTotal
.
Un exemple de JavaDocs pour Class le montre dans les paramètres:
public <U> Class<? extends U> asSubclass(Class<U> clazz)
Est-ce que cela montre un cas d'utilisation raisonnable?
cls
est un nom commun (en fait, le seul idiomatique) pour les variables / arguments conservant les classes réelles (celles que vous déclarez avec leclass
mot clé et dont tout est une instance).typedef char ínt
?iñt
. Voilà mon plan pour la domination du monde.Class c
).Réponses:
IMHO, c'est une très mauvaise idée. Les mots réservés sont réservés pour une raison, ce qui diminue la lisibilité.
Je suis également entièrement d'accord avec votre deuxième point. Nommer une variable
class
, même si vous pouviez le faire, serait aussi grave que de le nommertmp
oua
. Quel genre de classe? Une classe de quoi? Les noms doivent être descriptifs.la source
Le Guide de style de Python appelle spécifiquement ce problème et suggère:
Cela semble être une très bonne règle générale, en supposant que cela n’entre pas en conflit avec la sémantique d’une langue donnée.
la source
union
est un mot clé (comme en C)? Allez-vous l'appelerfoo
juste parce que ça ne devrait pas ressemblerunion
?cls
est le nom d'argument standard pour la méthode de classe. Aussi, par exemple, dans Django, les objets ont un.id
attribut, ce qui bien sûr est en conflit avec laid
fonction intégrée.merge
méthode aurait toujours besoin d'une documentation indiquant explicitement qu'elle implémente l'union et qu'elle a été renommée pour des raisons purement techniques.Odeur de code.
Le code ci-dessus ne me dit rien sur l'utilisation prévue des variables.
Même problème
Le code ci-dessus ne devrait pas nécessiter l'ajout d'une chaîne de mot-clé au nom de la variable. Si vous devez identifier les types par nom de variable, votre code est trop long. Condenser-refactor.
la source
Class<T>
paramètre, ce qui peut avoir un sens. Donc, je ne suis pas d'accord pour dire que c'est une odeur de code.Personnellement, je pense que c'est une option parfaitement valide pour votre style de code.
Ce sont des mots réservés pour que le compilateur n'ait pas à décider si vous voulez parler du mécanicien du langage ou de votre variable. Dans cet esprit, cela implique qu'ils attendent des utilisateurs qu'ils aient besoin d'une variable comme un mot réservé.
En parcourant la source fournie avec JDK 1.6 R21, je trouve 917 occurrences de "clazz". Apparemment, ils pensaient que c'était un style acceptable.
Qu'en pense votre équipe? Si vous pensez que c'est mauvais, mais que les 9 autres membres de votre équipe pensent que c'est bon, alors vous devez mordre la balle et l'accepter. Tant qu'il y a une communication sur ce qui va et ce qui ne va pas, et que vous abordez les problèmes que vous voyez comme vous les voyez, tout devrait bien se passer.
Ce que votre équipe ressent par rapport au style de code est plus important que mon opinion ou celle de quiconque dans ce message . Cela s’applique à cela et à toutes les décisions de style de code que vous pourriez avoir.
la source
klass
etclazz
c'est une mauvaise chose. Vous devez être cohérent afin qu'ils n'aient à l'apprendre qu'une seule fois. Et idéalement, cela est également précisé dans les directives de style des équipes. Ce n’est donc pas une surprise.Les fautes d'orthographe intentionnelles pour éviter les mots réservés sont une mauvaise idée.
Les fautes d'orthographe sont difficiles à distinguer de l'orthographe correcte, elles rendent donc le code plus difficile à lire.
Les fautes d'orthographe sont difficiles à retenir, de sorte que plusieurs erreurs d'orthographe incohérentes sont susceptibles d'entrer en concurrence dans le code, ce qui rend le code plus difficile à écrire et à lire.
Les mots réservés font référence à la langue utilisée pour résoudre le problème, pas au problème lui-même. Un nom de variable doit indiquer un concept lié au problème.
Il est donc préférable de choisir un nom descriptif alternatif ou, si aucune alternative satisfaisante n’existe, de qualifier le mot réservé de la manière suivante:
la source
Class clazz
ça sent "je ne me suis pas donné la peine d'essayer de trouver un bon nom". Une variable représente toujours quelque chose, et un bon nom le décrit. Je refuse d’imaginer qu’enclazz
toute circonstance, par exemple, soit le meilleur nom possible. Est-ce une référence à une classe -> class_reference, est une copie d'un objet de classe -> class_copy, etc. Peut-être aussi supprimer "class" et simplement utiliser le mot descriptif, par exempleIci clazz est la classe cible sur laquelle le contrôle doit être effectué, donc
serait beaucoup mieux décrire ce que le paramètre est utilisé pour que Clazz ne le fera jamais.
la source
classToBeAccessed
est un bon nom en effet (classToBeChecked
serait peut-être encore mieux).S'ils utilisent un nom réservé pour une variable, c'est une variable mal nommée. Même s'il s'agit d'un nom légitime, tel que Class pour le logiciel de classe.
Les variables mal nommées sont le signe d'un code mal pensé ou occasionnel - méfiez-vous des autres pièges du logiciel que vous gérez.
la source
Je pense que les fautes d'orthographe ou les abréviations intentionnelles sont une bonne idée si elles sont utilisées avec soin et cohérence .
Considérons en Java:
Le mot mal orthographié est le meilleur mot pour le travail réservé. Il y a deux endroits où vous pouvez être tenté de ne pas utiliser de fautes d'orthographe.
Dans le premier cas, il est assez évident que la paresse est rarement une bonne politique pour créer un code de qualité. Dans le second cas, choisissez une variable très courte. C'est ce que les mathématiciens font tout le temps, et les programmeurs pour les index. Il n'y a aucune raison de vous limiter à cela pour les indices s'il s'agit simplement d'une variable factice:
Vous ne perdez rien avec les noms de variables courts lorsque la méthode ou la structure du code vous indique ce qui doit être là.
la source
nextMeeting(MeetingRoom r)
est plein. CommentmeetingRoom
vous y rendre? Si c’était ti,nextMeeting(int meetingRoom)
je comprendrais, mais j’essaie d’ utiliser des noms de variables courts lorsque les informations sont déjà disponibles auprès d’autres sources .Klass
était une alternative quand il y avait un mot réservé . Je ne recommande pas d'utiliser une faute d'orthographe lorsque l'orthographe d'origine est disponible!J'ai vu des utilisations légitimes de
Class klass
la réflexion lorsque vous travaillez réellement avec une instance de laClass
classe.la source
userClass
ou une autre option.classInstance
plusklass
.classInstance
sont plutôt redondants. De plus, je pourrais imaginer quelque chose commeclass klass; Object classInstance = klass.newInstance;
.Pour les variables locales et les arguments formels, cela n'a pas d'importance.
N'importe quel nom est acceptable tant qu'il n'est pas intentionnellement trompeur ou gênant. Dans votre exemple:
peu importe que la variable locale unique soit "clazz" ou "klass" ou "cls" ou simplement "c". Je voudrais probablement juste en ligne l'expression:
La longueur d'un nom de variable doit être liée à la portée de la variable. Pour les variables locales dans les méthodes courtes (et elles devraient toutes être courtes), les noms très courts vont bien.
la source
ClassUtils.loadClass(benchmark.generatedClass())
=>benchmark.generatedClass()
- perdue enClassUtils.loadClass
cours de routeJe pense que les fautes d'orthographe sont toujours une mauvaise idée. Ce n'est tout simplement pas agréable pour vos lecteurs. Pour ma part, je me demanderais si j'ai oublié quelque chose quand je vois le mot
klass
. (Voulaient-ils direclass
, ou signifiaient-ils le pirate?) Au moins pour moi, toutes les fautes d'orthographe que je reconnais sont irritantes.Dans les rares cas où le mot réservé est vraiment la seule chose significative connue à propos de la variable, j'utiliserais les alternatives suivantes:
Si c'est un argument de fonction, utilisez
aClass
plutôt queclass
.S'il s'agit d'une variable locale ou membre, utilisez
myClass
plutôt queclass
.Si c'est un accesseur, utilisez
getClass()
plutôt queclass()
.Bien entendu, le préfixe ajouté est plutôt inutile et ne doit donc être utilisé qu'en dernier recours. Mais au moins, cela n’interfère pas avec l’analyseur mental de votre lecteur et c’est un moyen sûr d’éviter les mots réservés.
la source
Un avantage de l'orthographe créative est une meilleure capacité de recherche. Je pense qu'il est beaucoup plus facile de faire une recherche de code complète pour des choses uniques, plutôt que pour des mots courants, où trop souvent vous trouverez toutes les mauvaises choses, et mille d'entre elles. Par exemple, je possédais kzpg.com. Google que maintenant et vous verrez que quelques hits. C'est unique et donc très trouvable.
Mais dans une certaine mesure, j'estime que cette question est davantage une opinion que du fond. J'ai personnellement grandi à Forth où tout était question de mots et de beaucoup d'entre eux. On a appris à être très créatif pour sauver ses doigts. Au final, j'avais environ 640 000 caractères, plus ou moins dans ma base source. Il était donc important de garder les mots courts pour faire le travail.
la source