it-swarm.dev

Est-il mauvais d'utiliser des caractères Unicode dans les noms de variables?

J'ai récemment essayé d'implémenter un algorithme de classement, AllegSkill, pour Python 3.

Voici à quoi ressemble le calcul:

alt text

Non, vraiment.

Voici donc ce que j'ai écrit:

t = (µw-µl)/c  # those are used in
e = ε/c        # multiple places.
σw_new = (σw**2 * (1 - (σw**2)/(c**2)*Wwin(t, e)) + γ**2)**.5

En fait, je pensais qu'il était malheureux de Python 3 de ne pas accepter ou ² comme noms de variables.

>>> √ = lambda x: x**.5
  File "<stdin>", line 1
    √ = lambda x: x**.5
      ^
SyntaxError: invalid character in identifier

Suis-je hors de mon esprit? Dois-je avoir recours à une version ASCII uniquement? Pourquoi? ASCII seule la version de ce qui précède est plus difficile à valider pour l'équivalence avec les formules?

Attention, je comprends que certains glyphes Unicode se ressemblent beaucoup et certains comme (ou est-ce that) ou ╦ ne peuvent tout simplement pas avoir de sens dans le code écrit. Cependant, ce n'est guère le cas pour les mathématiques ou les glyphes de flèche.


Par requête, la seule version ASCII serait quelque chose dans le sens de:

winner_sigma_new = ( winner_sigma ** 2 *
                    ( 1 -
                     ( winner_sigma ** 2 -
                       general_uncertainty ** 2
                     ) * Wwin(t,e)
                    ) + dynamics ** 2
                   )**.5

... pour chaque étape de l'algorithme.

84
badp

Je suis convaincu que le simple remplacement de σ avec s ou sigma serait stupide, à la limite de mort cérébrale.

Quel est le gain potentiel? Voyons voir …

  • Améliore-t-elle la lisibilité? Non, pas du tout. S'il en était ainsi, la formule originale aurait sans aucun doute utilisé des lettres latines également.

  • Améliore-t-il l'écriture? À première vue, oui. Mais le deuxième, non. Parce que cette formule est ne changera jamais (enfin, "jamais"). Il ne sera normalement pas nécessaire de modifier le code, ni de l'étendre à l'aide de ces variables. L'écriture n'est donc pas - une seule fois - un problème.

Personnellement, je pense que les langages de programmation ont un avantage sur les formules mathématiques: vous pouvez utiliser des identifiants expressifs significatifs. En mathématiques, ce n'est normalement pas le cas, nous avons donc recours à des variables à une lettre, ce qui les rend parfois grecques.

Mais le grec n'est pas le problème. Les identifiants non descriptifs à une lettre sont.

Donc, soit conservez la notation d'origine… après tout, si le langage de programmation ne supporte Unicode dans les identifiants, il n'y a donc pas de barrière technique. Ou utilisez des identifiants significatifs. Ne remplacez pas seulement les glyphes grecs par des glyphes latins. Ou arabe, ou hindi.

54
Konrad Rudolph

Personnellement, je détesterais voir du code où je dois faire apparaître la carte des caractères pour la saisir à nouveau. Même si l'unicode correspond étroitement à ce qui se trouve dans l'algorithme, cela nuit vraiment à la lisibilité et à la capacité de modification. Certains éditeurs peuvent même ne pas avoir de police qui prend en charge ce caractère.

Que diriez-vous d'une alternative et ayez juste le dessus //µ = u et tout écrire en ascii?

34
TheLQ

Cet argument suppose que vous n'avez aucun problème à taper des unicodes ni à lire des lettres grecques

Voici l'argument: aimeriez-vous pi ou circular_ratio?

Dans ce cas, je préférerais pi à circulaire_ratio parce que je connais pi depuis que je suis à l'école primaire et je peux m'attendre à ce que la définition de pi soit bien ancrée à tous les programmeurs qui valent son sel. Par conséquent, cela ne me dérangerait pas de taper π pour signifier circulaire_ratio.

Mais qu'en est-il

winner_sigma_new = ( winner_sigma ** 2 *
                    ( 1 -
                     ( winner_sigma ** 2 -
                       general_uncertainty ** 2
                     ) * Wwin(t,e)
                    ) + dynamics ** 2
                   )**.5

ou

σw_new = (σw**2 * (1 - (σw**2)/(c**2)*Wwin(t, e)) + γ**2)**.5

Pour moi, les deux versions sont également opaques, tout comme pi ou π est, sauf Je n'ai pas appris cette formule à l'école primaire. winner_sigma et Wwin ne signifie rien pour moi, ni pour quiconque lit le code et n'utilise ni σw ne fait pas mieux.

Donc, en utilisant des noms descriptifs, par exemple total_score, winning_ratio, etc. augmenterait la lisibilité bien mieux que d'utiliser des noms ascii qui ne font que prononcer des lettres grecques . Le problème n'est pas que je ne peux pas lire les lettres grecques, mais je ne peux pas associer les caractères (grecs ou non) avec un "sens" de la variable.

Vous avez certainement compris le problème vous-même lorsque vous avez commenté: You should have seen the paper. It's just eight pages.... Le problème est que si vous basez votre nom de variable sur un papier, qui choisit des noms à une seule lettre pour la concision plutôt que pour la lisibilité (qu'ils soient grecs ou non), alors les gens devraient lire le papier pour pouvoir associer les lettres à un "sens"; cela signifie que vous mettez une barrière artificielle pour que les gens puissent comprendre votre code, et c'est toujours une mauvaise chose.

Même lorsque vous vivez dans un monde uniquement ASCII, les deux a * b / 2 et alpha * beta / 2 sont un rendu tout aussi opaque de height * base / 2, la formule de l'aire du triangle. L'illisibilité de l'utilisation de variables à lettre unique croît de façon exponentielle à mesure que la formule grandit en complexité, et la formule AllegSkill n'est certainement pas une formule triviale.

La variable de lettres simples n'est acceptable que comme compteur de boucle simple, qu'il s'agisse de lettres grecques simples ou de lettres simples ascii, je m'en fiche; aucune autre variable ne doit consister uniquement en une seule lettre. Je me fiche que vous utilisiez des lettres grecques pour vos noms, mais lorsque vous les utilisez, assurez-vous que je peux associer ces noms à un "sens" sans avoir besoin de lire un document arbitraire ailleurs.

À l'école primaire, cela ne me dérangerait certainement pas de voir des expressions mathématiques utilisant des symboles tels que: +, -, ×, ÷, pour l'arithmétique de base et √ () serait une fonction de racine carrée. Après avoir obtenu mon diplôme, je ne verrais aucun inconvénient à ajouter de nouveaux symboles brillants: ∫ pour l'intégration. Notez la tendance, ce sont tous des opérateurs. Les opérateurs sont beaucoup plus utilisés que les noms de variables, mais ils sont moins souvent réutilisés pour une signification entièrement différente (dans le cas où les mathématiciens réutilisent des opérateurs, la nouvelle signification conserve souvent certaines propriétés de base de l'ancienne signification; ce n'est pas le cas pour lors de la réutilisation des noms de variables).

En conclusion, non, il n'est pas mauvais d'utiliser des caractères Unicode pour les noms de variables; cependant, il est toujours mauvais d'utiliser des noms de lettre unique pour les noms de variable, et être autorisé à utiliser des noms Unicode n'est pas une licence pour utiliser des noms de variable à lettre unique.

31
Lie Ryan

Comprenez-vous le code? Est-ce que tous les autres qui ont besoin de le lire? Si c'est le cas, il n'y a pas de problème.

Personnellement, je serais heureux de voir le dos du code source ASCII uniquement.

14
user4051

Oui, vous êtes hors de votre esprit. Je ferais personnellement référence au numéro de papier et de formule dans un commentaire et j'écrirais tout en ASCII direct. Ensuite, toute personne intéressée pourrait corréler le code et la formule.

9
zvrba

Je dirais que l'utilisation de noms de variables Unicode est une mauvaise idée pour deux raisons:

  1. C'est un PITA à taper.

  2. Ils ressemblent souvent presque aux lettres anglaises. C'est la même raison pour laquelle je déteste voir des lettres grecques en notation mathématique. Essayez de dire rho en dehors de p. Ce n'est pas facile.

5
dsimcha

Dans ce cas, une formule mathématique complexe, je dirais que c'est parti.

Je peux dire qu'en 20 ans, je n'ai jamais eu à coder quelque chose d'aussi complexe et les lettres grecques le gardent proche des mathématiques originales. Si vous ne pouvez pas le comprendre, vous ne devriez pas le maintenir.

En disant que, si jamais je dois maintenir µ et σ dans le code standard des marais que vous m'avez légué, je vais savoir où vous vivez ...

4
gbn
  • Pro: ça a l'air sympa
  • Con: les caractères unicode et donc toute la signification peuvent se perdre dans la chaîne d'outils (éditeur, formateur de code, contrôle de version, ancien compilateur)

Quel est le risque pour vous? Le gain l'emporte-t-il sur le risque?

3
LennyProgrammers

Dans un avenir pas trop lointain, nous utiliserons tous des éditeurs de texte/IDE/navigateurs Web qui facilitent l'écriture du texte de modification, y compris les caractères grecs classiques, etc. (Ou peut-être aurons-nous tous appris à utiliser ce "caché") "fonctionnalité des outils que nous utilisons actuellement ...)

Mais jusqu'à ce que cela se produise, les caractères non ASCII dans le code source du programme seraient difficiles à gérer pour de nombreux programmeurs et sont donc une mauvaise idée si vous écrivez des applications qui pourraient avoir besoin d'être gérées par quelqu'un d'autre). .

(Par ailleurs, la raison pour laquelle vous pouvez avoir des caractères grecs mais pas des signes de racine carrée dans les identificateurs Python est simple. Les caractères grecs sont classés comme des lettres Unicode, mais le signe de la racine carrée est une non-lettre; voir http://www.python.org/dev/peps/pep-3131/ )

2
Stephen C

Vous n'avez pas dit quelle langue/compilateur vous utilisez, mais généralement la règle pour les noms de variable est qu'ils doivent commencer par un caractère alphabétique ou un trait de soulignement, et ne contenir que des caractères alphanumériques et des traits de soulignement. Un Unicode √ ne serait pas considéré comme alphanumérique, car il s'agit d'un symbole mathématique au lieu d'une lettre. Cependant σ pourrait l'être (car il est dans l'alphabet grec) et á serait probablement considéré comme alphanumérique.

2
tcrosley

J'ai posté le même genre de question sur StackOverflow

Je pense vraiment que cela vaut la peine d'utiliser unicode dans les problèmes mathématiques lourds, car cela permet de lire directement la formule, ce qui est impossible avec de l'ASCII ordinaire.

Imaginez une session de débogage: bien sûr, vous pouvez toujours écrire à la main la formule que le code est censé calculer pour voir si elle est correcte. Mais quatre-vingt-dix pour cent du temps, vous ne vous ennuierez pas et le bug peut rester caché pendant une longue période. Et personne n'est jamais prêt à regarder cette abstruse à 7 lignes, simple ASCII formule. Bien sûr, utiliser unicode n'est pas aussi bon qu'une formule rendue par tex, mais c'est bien mieux .

L'alternative d'utiliser des noms descriptifs longs n'est pas viable car en mathématiques, si l'identifiant n'est pas court, la formule sera encore plus compliquée (pourquoi pensez-vous que les gens, vers le XVIIIe siècle, ont commencé à remplacer "plus" par "+" et "moins" par "-"?).

Personnellement, j'utiliserais également des indices et des exposants (je les copie et les colle simplement depuis cette page ). Par exemple: (avait python autorisé √ comme identifiant)

√ = math.sqrt #function alias
c² = c**2
σʷ² = σʷ**2
γ² = γ**2
σ′ʷ = √(σʷ² * (1 - (σʷ²/c²)*Wʷⁱⁿ(t, e)) + γ²)

Où j'ai utilisé des exposants car il n'y a pas d'équivalent en indice unicode. (Malheureusement, le jeu de caractères en indice unicode est très limité. J'espère qu'un jour, la souscription en unicode sera considérée comme diacritique, c'est-à-dire une combinaison d'un caractère pour l'indice et d'un autre caractère pour la lettre souscrite)

Une dernière chose, je pense que cette conversation sur l'utilisation de caractères non ASCII est principalement biaisée, car de nombreux programmeurs ne traitent jamais des "notations mathématiques intensives en formules". Ils pensent donc que cette question n'est pas si importante, car ils n'ont jamais connu une partie importante de code qui nécessiterait l'utilisation d'identificateurs non ASCII. Si vous êtes l'un d'eux (et je l'étais jusqu'à récemment), considérez ceci: supposez que la lettre "a" ne fait pas partie de l'ASCII. Ensuite, vous aurez une assez bonne idée du problème de l'absence de lettres grecques, d'indices ou d'expositions lors du calcul de formules mathématiques non triviales.

1
Bérenger

personnellement, je suis motivé à considérer les langages de programmation comme un outil pour les mathématiciens dans ce contexte, car je n'utilise pas réellement des mathématiques qui ressemblent à ça dans ma vie. : D Et bien sûr, pourquoi ne pas utiliser ɛ ou σ ou autre chose - dans ce contexte, c'est en fait plus lisible.

(Bien que, je dois dire, ma préférence serait de prendre en charge les nombres en exposant comme appels de méthode directs, pas les noms de variables. Par exemple 2² = 2 ** 2 = 4, etc.)

0
roberto

Ce code est-il juste pour votre projet personnel? Si c'est le cas, devenez fou, utilisez ce que vous voulez.

Ce code est-il destiné à être utilisé par d'autres? c'est-à-dire, et une application open source en quelque sorte? Si c'est le cas, vous demandez probablement des ennuis car différents programmeurs utilisent différents éditeurs, et vous ne pouvez pas être sûr que tous les éditeurs prendront correctement en charge Unicode. De plus, tous les shells de commandes ne l'afficheront pas correctement lorsque le fichier de code source est tapé/caté, et vous pouvez rencontrer des problèmes si vous devez l'afficher en html.

0
GrandmasterB