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


82

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

Voici à quoi ressemble le calcul:

texte alternatif

Pas vraiment.

C'est alors 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 que c'est 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? Devrais-je avoir recours à une version uniquement ASCII? Pourquoi? Une version ASCII de ce qui précède ne serait-elle pas plus difficile à valider pour équivalence avec les formules?

Remarquez, je comprends que certains glyphes Unicode se ressemblent beaucoup et que d'autres, comme (ou est-ce que) ou, n'ont tout simplement pas de sens en code écrit. Cependant, ce n'est guère le cas pour les mathématiques ou les glyphes de flèche.


À la demande, la version ASCII uniquement ressemblerait à ceci:

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.


58
C'est fou, complètement illisible et incroyablement cool.
Dominique McDonnell


3
Je trouve très positif que Python n'accepte pas les opérations arithmétiques en tant que variables. Un signe de racine carrée doit indiquer l'opération consistant à prendre une racine carrée et ne doit pas être une variable.
David Thornley

4
@ David, il n'y a pas une telle distinction en Python. En effet, sqrt = lambda x: x**.5me obtient une fonction (plus précisément, un appelable): sqrt(2) => 1.41421356237.
Badp

4
OutputStream.🚽;

Réponses:


54

Je suis fermement convaincu que simplement remplacer σpar sou sigmaserait stupide, à la limite de la mort cérébrale.

Quel est le gain potentiel? Voyons voir …

  • Cela améliore-t-il la lisibilité? Non, pas le moins du monde. S'il en était ainsi, la formule originale aurait sans doute également utilisé les lettres latines.

  • Cela améliore-t-il l'écriture? Au premier regard, oui. Mais sur le second, non. Parce que cette formule ne changera jamais (enfin, «jamais»). Normalement, il ne sera pas nécessaire de changer le code ni de l'étendre à l'aide de ces variables. La possibilité d'écriture n'est donc, pour cette fois, pas un problème.

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

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

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


3
Certains outils ne peuvent pas lire les caractères Unicode, même si le langage de programmation prend en charge leur utilisation. Je n’appellerais pas cela une décision mortelle d’utiliser des noms de variable non-unicode, et cela reste vrai deux ans et demi après votre publication.
Gary S. Weaver

44
@Gary “Certains outils ne peuvent pas lire Unicode” - changez-les, c'est de la merde. Désolé, nous sommes en 2013, je n'ai aucune sympathie et encore moins de patience pour de tels outils. Traiter sans cesse les outils défectueux empêche le progrès.
Konrad Rudolph

3
@ KonradRudolph Mon point est que certains outils ne supportent pas et ne peuvent pas supporter Unicode pour quelque raison que ce soit, aussi, "changer les outils" n'est pas toujours la bonne réponse. Je conviens que Unicode est bon et que les outils doivent le comprendre, mais ce n’est pas toujours une option.

3
@John Je maintiens que "changer les outils" est une réponse appropriée. Votre exemple en particulier illustre un tel cas: les .propertiesfichiers Java sont faciles à analyser. Si vous travaillez réellement avec une chaîne d’outils qui, soutenue par des .propertiesfichiers, ne prend pas en charge Unicode, il est tout à fait raisonnable de laisser tomber ladite chaîne d’outils (et la remplacer vous-même, trouver une alternative ou, dans le pire des cas, la commander. ). Bien sûr, cela ne s'applique pas aux systèmes existants. Mais pour les systèmes existants, aucune des considérations relatives aux meilleures pratiques ne s'applique jamais.
Konrad Rudolph

8
Ces problèmes d’échange dont vous parlez semblent être avant tout le problème des développeurs Java et Windows. La plupart des environnements Linux standardisés sur UTF-8 il y a plus de dix ans. C'est définitivement un problème de chaîne d'outils. Arrêtez d'utiliser de mauvais outils.
riche remer

33

Personnellement, je détesterais voir le code où je dois afficher la carte des caractères pour la saisir à nouveau. Même si l'unicode correspond étroitement à ce qui est dans l'algorithme, cela nuit vraiment à la lisibilité et à la capacité d'édition. Certains éditeurs peuvent même ne pas avoir une police qui prend en charge ce caractère.

Qu'en est-il d'une alternative et juste avoir top //µ = uet tout écrire en ascii?


14
En passant, ne présumez pas que tous les claviers exposent confortablement les touches de codage standard. Ma disposition de clavier nécessite trois touches à taper {et }(ce qui échoue dans ttys btw) et une absence complète `et ~... comment un script Bash ne demanderait-il pas que je utilise une carte de caractères, si je n'utilisais pas de clavier personnalisé? :)
badp

4
J'ai installé un clavier grec à côté de mon clavier natif, et je peux basculer d'un clavier à l'autre. C'est utile quand on parle de math sur IM / email ... et j'avais déjà pensé à l'utiliser dans des scripts python.
Liori

18
Pouah. Juste en remplaçant les lettres grecques par des lettres simples? Aucun gain que ce soit. Utilisez des noms de variables significatifs, ou restez avec les noms du papier. Aucune raison d'être créatif.
Konrad Rudolph

12
Il suffit de ne pas confondre µ et μ ...
endolithe

4
Les éditeurs raisonnables disposent de méthodes de saisie raisonnables pour Unicode, ce qui facilite la modification de code de ce type. Par exemple, Emacs supporte (entre autres) le TeXet rfc1345. TeXest juste ce que cela ressemble il vous permet de taper \sigmapour σet \topour . rfc1345vous donne des combinaisons comme &s*pour σet &->pour . En règle générale, je ne m'inquiète pas d'accommoder les programmeurs utilisant des éditeurs moins capables qu'Emacs.
Tikhon Jelvis

31

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

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

Dans ce cas, je préférerais pi à circular_ratio parce que j'ai appris à connaître pi depuis mon école primaire et que je peux m'attendre à ce que la définition de pi soit bien enracinée dans l'esprit de tous les programmeurs dignes de ce nom. Par conséquent, cela ne me dérangerait pas de taper π pour signifier circular_ratio.

Cependant, 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 piou πest, sauf que je n'ai pas appris cette formule à l'école primaire. winner_sigmaet Wwinne signifie rien pour moi, ou pour toute autre personne qui lit le code, et l’utilisation de l’un ou de l’autre σwne le rend pas meilleur.

Ainsi, en utilisant des noms descriptifs, par exemple total_score, winning_ratio, etc. augmenterait la lisibilité beaucoup mieux que d' utiliser les noms de ascii qui prononcent simplement des lettres grecques . Le problème n’est pas que je ne puisse pas lire les lettres grecques, mais que je ne puisse pas associer les caractères (grecs ou non) à un "sens" de la variable.

Vous avez certainement compris vous le problème quand vous avez dit: You should have seen the paper. It's just eight pages.... Le problème est que si vous nommez votre variable sur un papier, qui choisit des noms d’une lettre pour la concision plutôt que pour la lisibilité (qu’ils soient grecs), il faudrait alors 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 si vous vivez dans un monde ASCII seulement, à la fois a * b / 2et alpha * beta / 2sont un rendu tout aussi opaque height * base / 2, la formule de la zone triangulaire. L'illisibilité d'utiliser des variables à une lettre augmente de façon exponentielle à mesure que la formule se complexifie et la formule AllegSkill n'est certainement pas une formule triviale.

La variable de lettres uniques n’est acceptable qu’en tant que compteur de boucle simple, qu’il s’agisse de lettres grecques à lettre unique ou ascii à lettre unique, peu importe; aucune autre variable ne devrait consister uniquement en une seule lettre. Peu importe si vous utilisez des lettres grecques pour vos noms, mais lorsque vous les utilisez, assurez-vous de pouvoir associer ces noms à un "sens" sans avoir à lire un document arbitraire ailleurs.

À l'école primaire, je ne verrais pas d'inconvénient à ce que les expressions mathématiques utilisant des symboles tels que: +, -, ×, ÷, pour l'arithmétique de base et √ () soient une fonction à racine carrée. Après avoir obtenu mon diplôme d'études secondaires, cela ne me dérangerait pas d'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 un sens totalement différent (dans le cas où les mathématiciens réutilisent des opérateurs, le nouveau sens conserve souvent certaines propriétés de base de l'ancien sens; ce n'est pas le cas pour lors de la réutilisation de noms de variables).

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


9
Pour être honnête, les formules ici n’ont pas plus de sens, même si je devais les utiliser à la error_on_measured_skill_with_99th_percent_confidenceplace sigma.
Badp

4
@badp: Noms longs! = Bons noms. Néanmoins, il est parfois impossible pour vous de choisir un bon nom (par exemple, lorsque vous ne comprenez que la formule, mais que vous ne comprenez pas pleinement ce que chaque partie de la formule fait (ce qui nécessite un niveau de compréhension totalement différent)), Ensuite, dans ce cas, la deuxième meilleure solution consiste à vous couvrir le cul de quelques commentaires (mieux que de les envoyer à un journal externe). Ajoutez un dictionnaire de données expliquant le nom des variables, par exemple // σw = skill level measurement error, etc.
Lie Ryan

1
@badp: Pour être honnête, avec juste cette information, sigma fait référence à un facteur fudge (pour ainsi dire), cela me donne une compréhension un peu meilleure de la formule que ce que sigma me frappe. Lorsque la formule est difficile à comprendre pour commencer, vous ne voulez pas ajouter d’opacité supplémentaire.
Lie Ryan

2
Oui. Cette. Malheureusement, je l’ai oublié en écrivant ma réponse.
Konrad Rudolph

3
Eh bien, toute personne travaillant dans le domaine des statistiques sait que σ signifie "écart type". C'est un symbole standard très connu dans ce domaine.
TRiG

14

Comprenez-vous le code? Est-ce que tout le monde qui a besoin de le lire? Si oui, il n'y a pas de problème.

Personnellement, je serais heureux de voir l’arrière du code source uniquement ASCII.


Terminé. (Je suppose que la dernière ligne vous demandait de voir la version du code uniquement en ASCII?) [] (Http: // ~)
badp

4
@badp: Non, c'était moi qui demandais à voir la mort du code uniquement en ASCII.

jusqu'à ce que vous commenciez à voir ce qu'il advient des fichiers source Unicode lors de l'atterrissage sur un système Windows 1252 ...

1
@ Thorbjørn: s'ils contiennent la nomenclature, nous espérons que rien ne se passera.

9

Oui, vous êtes hors de votre esprit. Personnellement, je ferais référence au papier et au numéro de formule dans un commentaire, et tout écrire en ASCII. Ensuite, toute personne intéressée serait capable de corréler le code et la formule.


5
Il était difficile pour moi de faire en sorte que le code et la formule correspondent au départ ...
badp

10
@Paul: Heureusement, Unicode a plus de 10 ans, donc l'objection a été traitée. Et bien qu’il n’y ait pas de vainqueur évident entre les différentes UTF, ce n’est pas un problème: il n’était pas censé en être un. Les distinguer est une tâche triviale pour les logiciels.
Konrad Rudolph

1
@Konrad: Je veux dire 10 ans à partir de maintenant . Un bon nombre de programmes ne supportent toujours pas Unicode. De plus, je ne suis pas d’accord avec votre affirmation - Il n’est pas trivial d’écrire une routine inverse générique qui gère les 3 utfs. Il doit y avoir un gagnant clair. Cela ne sert à rien de supporter 3 UTF différents (ne considérons pas les autres pages de code encore existantes).
Paul Nathan

3
@ Paul: À quelle fréquence devez-vous écrire une "routine inverse générique"? Les trois UTF servent des objectifs différents, et je ne pense pas que vous obtiendrez jamais votre souhait de consolidation.
Dean Harding

7
@Paul: vis ces programmes. Il y a assez de bons éditeurs qui savent comment gérer Unicode. Si un éditeur ne s'est toujours pas engagé dans le mouvement, laissez la sélection économique s'en charger. Et comme Dean l'a dit, les UTF ont des objectifs différents. C'est une bonne chose qu'ils existent. Et je ne vois pas l'intérêt de vos multiples routines inverses. Vous ne devez l'écrire qu'une seule fois (en ignorant pour l'instant les formulaires de normalisation): pour les points de code, pas pour les UTF individuels.
Konrad Rudolph

5

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

  1. Ils sont un PITA à taper.

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


6
Cela dépend de ce que vous utilisez pour les taper.
endolith

4

Dans ce cas, une formule mathématique complexe, je vous prierais d'y aller.

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

Dire que, si j'ai jamais à maintenir μ et σ dans bog code standard que vous me légués, je vais savoir où vous vivez ...


3
  • Pro: ça a l'air bien
  • Con: les caractères unicode et donc le sens entier peut être perdu dans la chaîne d'outils (éditeur, formateur de code, contrôle de version, ancien compilateur)

Quelle est l'ampleur du risque pour vous? Le gain dépasse-t-il le risque?


2
Chaîne d'outil? Quelle chaîne d'outils?
Badp

2
Editeur, formateur de code, contrôle de version, ancien compilateur. Chaque outil et personne touchant votre dossier. J'ai eu une mauvaise expérience avec les outils de bousiller avec les fichiers Unicode, YMMV.
LennyProgrammers

2

Dans un avenir pas si lointain, nous utiliserons tous des éditeurs de texte / IDE / navigateurs Web qui facilitent l’écriture de textes de montage comprenant des caractères grecs classiques, etc. "fonctionnalité dans les outils que nous utilisons actuellement ...)

Mais jusqu'à ce que cela se produise, la plupart des programmeurs auraient du mal à gérer les caractères non ASCII dans le code source du programme. Ils sont donc une mauvaise idée si vous écrivez des applications pouvant nécessiter la maintenance de quelqu'un d'autre.

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


Je pense que ce serait une bonne idée de créer un IME capable de traduire les caractères pour les utilisateurs qui ne peuvent pas les saisir directement.
AndrejaKo

Oui, plus ou moins quand nous aurons basculé sur DVORAK. :(
badp

1
@AndrejaKo Linux a un IME qui accepte les commandes de style LaTeX - c’est-à-dire que vous tapez \muet installe µ.
Badp

@badp Merci beaucoup! Je vais essayer ça la prochaine fois que je démarre!
AndrejaKo

Emacs supporte de nombreuses méthodes de saisie qui facilitent la frappe des symboles Unicode. (Y compris un TeX qui est ce que j'utilise.) Emacs est à peine futuriste. (Il est génial, bien sûr.)
Tikhon Jelvis

2

Vous n'avez pas indiqué la langue / le compilateur que vous utilisez, mais la règle pour les noms de variables 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 caractères de soulignement. Un Unicode √ ne serait pas considéré alphanumérique, car il s’agit d’un symbole mathématique et non d’une lettre. Cependant, σ pourrait être (puisqu'il est dans l'alphabet grec) et á serait probablement considéré comme alphanumérique.


1

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

Je pense vraiment qu'il vaut la peine d'utiliser Unicode dans les problèmes mathématiques complexes, car cela permet de lire la formule directement, ce qui est impossible avec du code ASCII simple.

Imaginez une session de débogage: vous pouvez bien sûr toujours écrire à la main la formule que le code est censé calculer pour voir si elle est correcte. Mais dans 90% des cas, vous ne vous en soucierez pas et le virus peut rester caché pendant très longtemps. Et personne n’est jamais disposé à regarder cette formule ASCII simple et abstraite à 7 lignes. Bien sûr, l’utilisation de l’unicode n’est pas aussi efficace que celle d’une formule au rendu tex, mais c’est bien mieux.

L’utilisation de noms descriptifs longs n’est pas viable, car en maths, si l’identifiant n’est pas court, la formule paraîtra encore plus compliquée (pourquoi pensez-vous que les gens, au XVIIIe siècle environ, ont commencé à remplacer "plus" par "+" et "moins" par "-"?).

Personnellement, je voudrais aussi utiliser des indices et des indices supérieurs (je les copie-collent depuis cette page ). Par exemple: (Python avait-il autorisé √ comme identifiant)

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

Où j’ai utilisé les indices supérieurs car il n’existe pas d’équivalent en indice en unicode. (Malheureusement, le jeu de caractères en indice unicode est très limité. J'espère qu'un jour, l'index en unicode sera considéré comme un signe diacritique, c'est-à-dire une combinaison d'un caractère pour l'indice et d'un autre pour la lettre en indice)

Une dernière chose, je pense que cette conversation sur l’utilisation de caractères non-ASCII est essentiellement biaisée, car de nombreux programmeurs ne traitent jamais avec des "notations mathématiques intensives en formules". Ils pensent donc que cette question n’est pas si importante, car ils n’ont jamais expérimenté une partie importante du code nécessitant l’utilisation d’identifiants non-ASCII. Si vous êtes l'un d'entre eux (et je l'étais jusqu'à récemment), considérez ceci: supposons que la lettre "a" ne fasse pas partie de l'ASCII. Vous aurez alors une assez bonne idée du problème de l’absence de lettres grecques, d’indices, d’indices supérieurs lors du calcul de formules mathématiques non triviales.


0

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

Ce code est-il destiné aux autres? c'est-à-dire, et une application open source de quelque sorte? Si tel est le cas, vous ne faites probablement que demander des ennuis, car différents programmeurs utilisent différents éditeurs et vous ne pouvez pas être certain que tous les éditeurs prendront en charge le format Unicode correctement. En outre, tous les interpréteurs de commandes ne l’afficheront pas correctement lorsque le fichier de code source est de type catd / cat'd, et vous pouvez rencontrer des problèmes si vous avez besoin de l’afficher au format HTML.


0

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

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


-2

Qu'est - ce qui est σ, ce qui est W, ce qui est ε, cet ce qui est γ?
Vous devez nommer vos variables de manière à expliquer leur objectif.
Personnellement, je battrais tous ceux qui laisseraient la version Unicode ou ASCII à ma charge, bien que la version ASCII soit meilleure.

Ce qui est mal, c'est d'appeler des variables σou sou sigmaou valueou var1, parce que cela ne donne aucune information.

En supposant que vous écriviez votre code en anglais (comme je pense que vous devriez l’où que vous soyez), ASCII devrait suffire à donner des noms significatifs à vos variables, de sorte qu’il n’y a aucun besoin réel d’Unicode.


2
Et s'il faisait un copier / coller du papier et en faisait ensuite une partie de son code source sous forme de commentaire malgré les noms de variable à un caractère?
Brian

19
Un grand nombre de ces noms de variables ont une signification forte pour ceux qui sont familiers avec le domaine du problème. Pour quelqu'un de familier avec le domaine, les noms anglais pourraient être moins lisibles que des noms comme sigma ou rho.
dsimcha

3
Je crains que quelque chose comme ce rank_error_with_99_pct_confidencesoit un peu trop long pour cela et ne rende pas les formules plus faciles à comprendre. AllegSkill / TrueSkill appellent ces sigma, je pense donc qu'il est parfaitement acceptable pour moi de conserver le nom de domaine spécifique qu'ils ont.
Badp

3
@badp: les bons noms sont concis et descriptifs; mais il n'est pas nécessaire que ce soit complètement descriptif. Pour votre sigma, il est parfaitement bon d’utiliser rank_erroret de placer le détail supplémentaire concernant une confiance de 99% dans la documentation / le commentaire quelque part.
Lie Ryan

1
@dsimcha: Je pense que ceux qui sont familiers avec un domaine particulier sont nettement plus rares que ceux qui n'en ont jamais entendu parler. Et je pense que ceux qui connaissent le domaine seront capables de gérer les noms anglais clairs, tandis que ceux qui ne le connaissent pas seront complètement incapables de comprendre ce qui se passe si tout est obscurci par des variables grecques à une lettre.
back2dos

-2

Pour les noms de variables ayant des origines mathématiques bien connues, cela est tout à fait acceptable - même préféré. Mais si vous envisagez de distribuer le code, vous devez placer ces valeurs dans un module, une classe, etc., de sorte que l'auto-complétion IDE puisse gérer la "saisie" des caractères étranges.

Utiliser √ ou ² dans un identifiant - pas vraiment.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.