Est-ce une bonne idée d'utiliser des symboles unicode comme identifiants Java?
J'ai un extrait de code qui ressemble à ceci:
double Δt = lastPollTime - pollTime;
double α = 1 - Math.exp(-Δt / τ);
average += α * (x - average);
Quelle est la mauvaise idée d'utiliser des caractères unicode dans les identifiants Java? Ou est-ce tout à fait acceptable?
7 answers
C'est une mauvaise idée, pour diverses raisons.
Les claviers de nombreuses personnes ne supportent pas ces caractères. Si je devais maintenir ce code sur un clavier qwerty (ou tout autre sans lettres grecques), je devrais copier et coller ces caractères tout le temps.
Les éditeurs ou les terminaux de certaines personnes peuvent ne pas afficher ces caractères correctement. Par exemple, certains éditeurs (malheureusement) utilisent toujours une variante ISO-8859 (latin) par défaut. La principale raison pour laquelle ASCII est toujours si répandue est que cela fonctionne presque toujours.
-
Même si les caractères peuvent être rendus correctement, ils peuvent causer de la confusion. Tout droit du soleil (emphase à moi):
Les identifiants qui ont la même apparence externe peuvent encore être différents. Par exemple, les identifiants constitués des lettres simples LETTRE LATINE MAJUSCULE A (A, \u0041) , LETTRE LATINE MINUSCULE A (a, \ u0061), LETTRE GRECQUE MAJUSCULE ALPHA (A, \ u0391), LETTRE CYRILLIQUE MINUSCULE A (a, \u0430) et MATHÉMATIQUE GRAS ITALIQUE PETIT A (a, \ ud835 \ udc82) sont tous différents.
...
Les caractères composites Unicode sont différents des caractères décomposés. Par exemple, une LETTRE MAJUSCULE LATINE A AIGUË (Á, \u00c1) pourrait être considérée comme identique à une LETTRE MAJUSCULE LATINE A (A, \u0041) immédiatement suivie d'une LETTRE AIGUË NON ESPACÉE (, \u0301) lors du tri, mais ces identifiants sont différents.
Ce n'est en aucun cas un imaginaire problème: α (U + 03b1 LETTRE GRECQUE ALPHA) et ⍺ (U + 237a APL SYMBOLE FONCTIONNEL ALPHA) sont des caractères différents!
Il n'y a aucun moyen de dire quels caractères sont valides. Les caractères de votre code fonctionnent, mais lorsque j'utilise le SYMBOLE FONCTIONNEL ALPHA, mon compilateur Java se plaint de "caractère illégal: \9082". Même si le symbole fonctionnel serait plus approprié dans ce code. Il ne semble pas y avoir de règle solide sur les caractères acceptables, sauf demandant
Character.isJavaIdentifierPart().Même si vous pouvez le compiler, il semble douteux que toutes les implémentations de machines virtuelles Java aient été rigoureusement testées avec des identifiants Unicode. Si ces caractères ne sont utilisés que pour les variables dans la portée de la méthode, ils devraient être compilés, mais s'ils sont membres de la classe, ils se retrouveront également dans le fichier
.class, éventuellement casser votre programme sur des implémentations JVM boguées.
Semble bon car il utilise les symboles corrects, mais combien de vos équipes connaîtront les frappes de ces symboles?
J'utiliserais une représentation anglaise juste pour le rendre plus facile à taper. Et d'autres pourraient ne pas avoir un jeu de caractères qui prend en charge ces symboles mis en place sur leur PC.
, Il est parfaitement acceptable si c'est acceptable dans votre groupe de travail. Beaucoup de réponses ici fonctionnent sur l'hypothèse arrogante que tout le monde programme en anglais. Les programmeurs non anglais ne sont en aucun cas rares de nos jours et ils deviennent moins rares à un rythme accéléré. Pourquoi devraient-ils se limiter aux versions anglaises alors qu'ils ont une langue parfaitement bonne à leur disposition?
Arrogance anglophone mis à part, il y a d'autres raisons légitimes d'utiliser identificateurs non anglais. Si vous écrivez des paquets mathématiques, par exemple, utiliser le grec est très bien si votre cible est d'autres mathématiciens. Pourquoi les gens devraient-ils taper "delta" dans votre groupe de travail alors que tout le monde peut comprendre "Δ" et probablement le taper plus rapidement? Presque tous les domaines problématiques auront leur propre jargon et parfois ce jargon est exprimé dans autre chose que l'alphabet latin. Pourquoi diable voudriez-vous essayer de tout bloquer en ASCII?
Ce code est bien à lire, mais horrible à maintenir-Je suggère d'utiliser des identifiants anglais simples comme ceci:
double deltaTime = lastPollTime - pollTime;
double alpha = 1 - Math.exp(-delta....
C'est une excellente idée. Honn. Ce n'est tout simplement pas facilement praticable à l'époque. Gardons une référence pour l'avenir. J'aimerais aimer voir des triangles, des cercles, des carrés, etc... dans le cadre du code du programme. Mais pour l'instant, essayez de le réécrire, comme le suggère Crozin.
Pourquoi pas? Si les personnes travaillant sur ce code peuvent les taper facilement, c'est acceptable.
Mais dieu aide ceux qui ne peuvent pas afficher unicode, ou qui ne peuvent pas les taper.
Dans un monde parfait, ce serait la voie recommandée.
Malheureusement, vous rencontrez des encodages de caractères lorsque vous vous déplacez en dehors des caractères ASCII 7 bits simples (UTF-8 est différent de ISO-Latin-1 est différent de UTF-16, etc.), ce qui signifie que vous finirez par rencontrer des problèmes. Cela m'est arrivé lors du passage de Windows à Linux. Nos personnages scandinaves nationaux ont cassé dans le processus, mais heureusement était seulement dans les cordes. Nous avons ensuite utilisé l'encodage \ u pour tous de ceux-ci.
Si vous pouvez être absolument certain que vous ne rencontrerez jamais une telle chose - par exemple si vos fichiers contiennent une nomenclature appropriée - alors par tous les moyens, faites-le. Il permet de rendre votre code plus lisible. Si au moins la plus petite quantité de doute, alors ne le faites pas.
(Veuillez noter que "utiliser des langues non anglaises" est une question différente. Je pense juste à utiliser des symboles au lieu de lettres).