Erreurs d'orthographe intentionnelle pour éviter les mots réservés

45

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:

  • klassou clazzpour la classe :Class clazz = ThisClass.class
  • kountpour 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é - itemClassou 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?

Nicole
la source
9
Pour mémoire: En Python, clsest un nom commun (en fait, le seul idiomatique) pour les variables / arguments conservant les classes réelles (celles que vous déclarez avec le classmot clé et dont tout est une instance).
14
Tu n'aimes pas typedef char ínt?
Jeff
14
@ muntoo Tu as raison. Je reçois aussi des erreurs de compilateur pour iñt. Voilà mon plan pour la domination du monde.
Jeff
1
J'ai enfreint cette règle ... et maintenant je me sens honteux.
Jmq
3
Ne le fais pas. Je peux honnêtement dire que je n’ai jamais vu cela auparavant, et si je le faisais, je le renommerais immédiatement. Abritez simplement si vous devez utiliser un nom de variable non descriptif ( Class c).
Cody Gray

Réponses:

63

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 nommer tmpou a. Quel genre de classe? Une classe de quoi? Les noms doivent être descriptifs.

Dima
la source
15
"Les mots réservés sont réservés pour une raison" <- This. (Ce qui, ironiquement, est réservé.)
trycatch
16
+1 parce que tu as raison. Mais si vous écriviez un logiciel de planification de classe, ou quelque chose de ce
genre
8
Meh " Les mots réservés sont réservés pour une raison ", ce qui signifie que les concepteurs de langage sont paresseux. Il existe de nombreux langages sophistiqués dans lesquels les mots ne sont réservés que dans les endroits spécifiques où ils sont utilisés. Mais Ritchie a commencé cette tendance lorsqu'il avait besoin d'un compilateur léger pour C, et la plupart des concepteurs de langage l'ont appris à partir de là.
Ross Patterson
14
non Ross, c'est parce que les programmeurs (et les lecteurs en général) s'attendent à ce que les choses aient une signification raisonnablement non ambiguë (c'est pourquoi l'apprentissage des langues étrangères est souvent si difficile, toutes les choses ayant une double signification, ou différentes de la langue que vous avez parlée depuis l’enfance où vous ne remarquerez jamais ces ambiguïtés car elles font partie de votre patrimoine culturel).
Jwenting
3
@AlexanderMorou Non, et la plupart des concepteurs de langage n'ont pas non plus, ils commencent simplement par le design de quelqu'un d'autre. Mais regardez Algol, Fortran, PL / I, Rexx et d'autres langages non basés sur C, et vous verrez que les grammaires sans mots réservés sont certainement possibles, mais plus difficiles encore. Ritchie avait une bonne raison - les utilisateurs d'Unix estimaient que chaque frappe était importante, et sur un PDP-11, chaque cycle de processeur comptait. Aujourd'hui? Pas tellement.
Ross Patterson
21

Le Guide de style de Python appelle spécifiquement ce problème et suggère:

Si votre nom d'attribut public entre en conflit avec un mot clé réservé, ajoutez un trait de soulignement de fin unique à votre nom d'attribut. Ceci est préférable à une abréviation ou à une orthographe corrompue.

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.

Ryan
la source
7
Je pense que c'est vraiment un mauvais conseil d'un guide de style. Si le nom de votre attribut est si proche d'un mot clé, vous devriez trouver un meilleur nom. Le simple fait de mettre un trait de soulignement à la fin n'ajoute aucun sens et risque de confondre le prochain gars qui lit le code.
Wayne Johnston
18
@Wayne: Comment allez-vous nommer l'opération d'union dans une structure de recherche d'union quand unionest un mot clé (comme en C)? Allez-vous l'appeler foojuste parce que ça ne devrait pas ressembler union?
Fred Foo
OTOH, clsest le nom d'argument standard pour la méthode de classe. Aussi, par exemple, dans Django, les objets ont un .idattribut, ce qui bien sûr est en conflit avec la idfonction intégrée.
vartec
1
@GoloRoden Je n'ai jamais entendu personne dire qu'il "réunissait" deux ensembles lors du calcul de l'union. Cela ne fait tout simplement pas partie du jargon. "Fusionner" serait mieux, mais une mergemé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.
Fred Foo
2
@GoloRoden Selon Merriam-Webster, ce n'est pas un verbe, mais voyez cette réponse .
Maaartinus
18

Odeur de code.

string stringVariable = "";

Le code ci-dessus ne me dit rien sur l'utilisation prévue des variables.

class Klass

Même problème

string UserNameString = "bmackey"

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.

P.Brian.Mackey
la source
Cela ne vous dit rien car ce n'est pas du "code", c'est une déclaration de variable isolée. Une "classe" ou un "klass" peuvent très bien vous dire tout ce que vous devez savoir. Par exemple, une méthode générique peut recevoir un 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.
Andres F.
5

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.

CorsiKa
la source
1
Oui, mais votre équipe finira par changer. Bien des années plus tard, il y aura un pauvre type qui regardera votre code plein de klasses et de clazzes et qui dira "WTF!".
MrFox
4
Si vous utilisez les deux klasset clazzc'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.
CorsiKa
Le code est écrit non seulement pour les membres de votre équipe, mais pour le reste du monde. Lorsque votre équipe se trouve dans un bus qui passe au-dessus d'une falaise, quelqu'un d'autre commence à lire le code. Utilisez des noms qui décrivent de manière complète et concise ce qu’est la variable, et non comment elle est représentée.
Rob K
1
Non, simplement non. Votre équipe est beaucoup, beaucoup plus susceptible de faire tourner les membres lentement au fil du temps. Vous pouvez prévoir qu'une personne soit touchée par un bus, mais vous ne pouvez pas prévoir que toute votre équipe soit frappée par un bus. La plupart du code est écrit pour peut-être une douzaine de personnes ayant besoin de le lire, la moitié lors de la révision du code.
CorsiKa
4

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:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> benchmarkedClass = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(benchmarkedClass, benchmark.generatedMethod());
}
utilisateur40989
la source
3

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’en clazztoute 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 exemple

java.lang.SecurityManager.checkMemberAccess(Class<?> clazz, int which)
Parameters
    clazz -- the class that reflection is to be performed on.

Ici clazz est la classe cible sur laquelle le contrôle doit être effectué, donc

checkMemberAccess(Class<?> target, int which)

serait beaucoup mieux décrire ce que le paramètre est utilisé pour que Clazz ne le fera jamais.

Hlovdal
la source
IMHO ce n'est pas mieux, vous pouvez l'appeler 'classToBeAccessed` ou autre chose, mais tout nom plus descriptif ne fait que montrer l'évidence. J'aime les noms longs uniquement s'ils fournissent des informations utiles.
Maaartinus
1
classToBeAccessedest un bon nom en effet ( classToBeCheckedserait peut-être encore mieux).
hlovdal
1

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.

thursdaysgeek
la source
0

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:

class X { public X() { } }
X x = new X();
x.getClass;  // Wha?  How does "get" help anything?
x.class;     // Best, but requires more lexer/parser work
x.klass;     // At least as good as getClass
x.clazz;     // Same

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.

  1. Vous n'avez pas envie de penser à un bon nom
  2. Vous voulez juste une variable factice et elle n'a pas besoin d'un nom descriptif

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:

boolean isMyName(String testName) { return myName.equals(testName); }
boolean isMyName(String s) { return myName.equals(s); }

Date nextMeeting(Klass klass) { return /* something */ }
Date nextMeeting(Klass k) { return /* something */ }

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à.

Rex Kerr
la source
2
Je suis désolé, je ne peux pas être d'accord. Comment nextMeeting fonctionne-t-il exactement? La logique est obscure. Vous me forcez à consulter la définition de Klass chaque fois que je lis votre code car son nom n'a pas de sens. Si vous aviez plutôt nextMeeting (MeetingRoom meetingRoom), j'aurais une définition de classe de moins (klass? Clazz?) À lire et donc à être plus productif. Le code est lu beaucoup plus qu'écrit.
MrFox
@suslik - nextMeeting(MeetingRoom r)est plein. Comment meetingRoomvous 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 .
Rex Kerr
Mon post portait plus sur l'existence de Klass dans la base de code. Je suis d’accord parfois avec des noms de variables courts, mais si vos méthodes sont longues et que vous devez continuer à vous assurer que "r" est une salle de réunion, ce n’est pas terrible non plus. Je suis curieux de savoir quels sont les inconvénients de meetingRoom? Espace horizontal? Trop long à taper?
MrFox
@suslik - Oui, vous perdez le contexte horizontal avec des noms de variable longs. Vous perdez le contexte vertical avec des méthodes longues, il est donc préférable d’essayer de les éviter (mais je suis d’accord si vous le faites quand même, vous voudrez probablement que vos noms de variables soient de meilleurs rappels). 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!
Rex Kerr
0

J'ai vu des utilisations légitimes de Class klassla réflexion lorsque vous travaillez réellement avec une instance de la Classclasse.

Matthieu
la source
2
La question n'est pas de savoir s'il existe un cas où vous avez une instance, mais si vous devez utiliser cette orthographe ou un nom plus descriptif, tel que userClassou une autre option.
Nicole
2
Dans ce cas, je préférerais classInstanceplus klass.
Konrad Morawski
2
@ KonradMorawski: Mais tous les objets avec lesquels vous travaillez sont des instances, de sorte qu'ils classInstancesont plutôt redondants. De plus, je pourrais imaginer quelque chose comme class klass; Object classInstance = klass.newInstance;.
Maaartinus
0

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 ou clazz pour la classe: classe clazz = ThisClass.class

kount pour count 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.

Cependant, il est si courant que je ne peux pas m'empêcher de me demander si je suis le seul? Quelqu'un a des conseils ou même mieux, cité des recommandations de programmeurs respectés sur cette pratique?

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:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}

peu importe que la variable locale unique soit "clazz" ou "klass" ou "cls" ou simplement "c". Je voudrais probablement juste en ligne l'expression:

return findBenchmarkMethod(ClassUtils.loadClass(benchmark.generatedClass()),
                           benchmark.generatedMethod());

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.

Kevin Cline
la source
votre ligne semble incorrecte ClassUtils.loadClass(benchmark.generatedClass())=> benchmark.generatedClass()- perdue en ClassUtils.loadClasscours de route
mordure le
0

Je 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 dire class, 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 aClassplutôt que class.

  • S'il s'agit d'une variable locale ou membre, utilisez myClassplutôt que class.

  • Si c'est un accesseur, utilisez getClass()plutôt que class().

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.

cmaster
la source
0

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.

Vue elliptique
la source
Ce lien est cassé maintenant.
Peter Mortensen