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

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?

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.

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.

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.

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.

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());
}

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.

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.

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

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

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.

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.

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.