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

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

Voici à quoi ressemble le calcul:

_{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.

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.

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?

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.

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.

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.

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.

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

• 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?

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 / )

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.

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.

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.

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

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.

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.