¿Es malo usar caracteres Unicode en nombres de variables? [cerrado]

Recientemente intenté implementar un algoritmo de clasificación, AllegSkill, en Python 3.

Así es como se ven las matemáticas:

_{No realmente.}

Esto es lo que escribí:

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

De hecho, pensé que es desafortunado de Python 3 no aceptar √o ²como nombres de variables.

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

¿Estoy fuera de mi mente? ¿Debería haber recurrido a una versión solo ASCII? ¿Por qué? ¿No sería más difícil validar una única versión ASCII de lo anterior para determinar la equivalencia con las fórmulas?

_{Eso sí, entiendo que algunos glifos Unicode se parecen mucho entre sí y algunos como (o es eso ▗▖) o ╦ simplemente no tienen sentido en el código escrito. Sin embargo, este no es el caso para las matemáticas o los glifos de flecha.}

Por solicitud, la única versión ASCII sería algo similar a:

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

... por cada paso del algoritmo.

Siento firmemente que solo reemplazar σcon so sigmasería estúpido, bordeando la muerte cerebral.

¿Cuál es la ganancia potencial? Bien, veamos …

• ¿Mejora la legibilidad? No, no en lo más mínimo. Si así fuera, la fórmula original sin duda también habría utilizado letras latinas.

• ¿Mejora la capacidad de escritura? A primera vista, sí. Pero en el segundo, no. Porque esta fórmula nunca va a cambiar (bueno, "nunca"). Normalmente no habrá necesidad de cambiar el código, ni de extenderlo usando estas variables. Entonces, la capacidad de escritura no es un problema, solo por esta vez.

Personalmente, creo que los lenguajes de programación tienen una ventaja sobre las fórmulas matemáticas: puede usar identificadores significativos y expresivos. En matemáticas, este no suele ser el caso, por lo que recurrimos a variables de una letra, ocasionalmente haciéndolas griegas.

Pero el griego no es el problema. Los identificadores no descriptivos de una letra son.

Así que, o mantener la notación original, ... después de todo, si el lenguaje de programación lo hace compatible con Unicode en los identificadores, así que no hay obstáculo técnico. O use identificadores significativos. No solo reemplace los glifos griegos con glifos latinos. O árabes, o hindúes.

Personalmente, odiaría ver el código donde tengo que mostrar el mapa de caracteres para volver a escribirlo. A pesar de que el Unicode coincide estrechamente con lo que está en el algoritmo, está realmente perjudicando la capacidad de lectura y la capacidad de edición. Es posible que algunos editores ni siquiera tengan una fuente que admita ese carácter.

¿Qué tal una alternativa y simplemente tener arriba //µ = uy escribir todo en ascii?

Este argumento asume que no tienes problemas para escribir unicodes ni leer letras griegas

Aquí está el argumento: ¿te gustaría pi o circular_ratio?

En este caso, preferiría pi a circular_ratio porque aprendí sobre pi desde que estaba en la escuela primaria y puedo esperar que la definición de pi esté bien arraigada para cada programador que valga la pena. Por lo tanto, no me importaría escribir π para significar circular_ratio.

Sin embargo, ¿qué pasa con

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

o

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

Para mí, ambas versiones son igualmente opacas, como pio πes, excepto que no aprendí esta fórmula en la escuela primaria. winner_sigmay Wwinno significa nada para mí, ni para nadie más que lea el código, y usar ninguno σwno lo hace mejor.

Por lo tanto, el uso de nombres descriptivos, por ejemplo total_score, winning_ratioetc. aumentaría la legibilidad mucho mejor que el uso de nombres ascii que simplemente pronuncian letras griegas . El problema no es que no puedo leer letras griegas, pero no puedo asociar los caracteres (griegos o no) con un "significado" de la variable.

Por supuesto que entiende el problema usted mismo cuando usted comentó: You should have seen the paper. It's just eight pages.... El problema es que si basa su denominación variable en un documento, que elige nombres de una letra por concisión en lugar de legibilidad (independientemente de si son griegos), entonces las personas tendrían que leer el documento para poder asociar las letras con un "sentido"; Esto significa que está poniendo una barrera artificial para que las personas puedan entender su código, y eso siempre es algo malo.

Incluso cuando se vive en un mundo sólo ASCII, tanto a * b / 2y alpha * beta / 2es una representación igual de opaca height * base / 2, la fórmula del área del triángulo. La imposibilidad de leer variables de una sola letra aumenta exponencialmente a medida que la fórmula crece en complejidad, y la fórmula AllegSkill ciertamente no es una fórmula trivial.

La variable de letras individuales solo es aceptable como un contador de bucle simple, ya sean griegas de una letra o ascii de una letra, no me importa; ninguna otra variable debe consistir únicamente en una sola letra. No me importa si usa letras griegas para sus nombres, pero cuando las use, asegúrese de que pueda asociar esos nombres con un "significado" sin necesidad de leer un documento arbitrario en otro lugar.

Cuando estoy en la escuela primaria, definitivamente no me importaría ver expresiones matemáticas usando símbolos como: +, -, ×, ÷, para la aritmética básica y √ () sería una función de raíz cuadrada. Después de graduarme de la escuela primaria, no me importaría agregar nuevos símbolos brillantes: ∫ para la integración. Tenga en cuenta la tendencia, estos son todos los operadores. Los operadores se usan mucho más que los nombres de variables, pero se reutilizan con menos frecuencia para un significado completamente diferente (en el caso de que los matemáticos reutilicen operadores, el nuevo significado a menudo todavía tiene algunas propiedades básicas del significado anterior; este no es el caso para al reutilizar nombres de variables).

En conclusión, no, no está mal usar caracteres Unicode para nombres de variables; sin embargo, siempre es malo usar nombres de letras simples para nombres de variables, y tener permiso para usar nombres Unicode no es una licencia para usar nombres de variables de letras únicas.

¿Entiendes el código? ¿Todos los demás que necesitan leerlo? Si es así, no hay problema.

Personalmente, me alegraría ver la parte posterior del código fuente solo ASCII.

Sí, estás loco. Yo personalmente haría referencia al papel y al número de fórmula en un comentario, y escribiría todo en ASCII directo. Entonces, cualquier persona interesada podría correlacionar el código y la fórmula.

Diría que usar nombres de variables Unicode es una mala idea por dos razones:

1. Son una PITA para escribir.

2. A menudo se ven casi iguales a las letras en inglés. Esta es la misma razón por la que odio ver letras griegas en notación matemática. Intenta distinguir rho aparte de p. No es fácil.

En este caso, una fórmula matemática compleja, diría que anímate.

Puedo decir que en 20 años nunca he tenido que codificar algo tan complejo y las letras griegas lo mantienen cerca de las matemáticas originales. Si no puede entenderlo, no debería mantenerlo.

Diciendo que, si alguna vez tengo que mantener μ y σ en el pantano de código estándar que me legó, yo voy a averiguar dónde vivo ...

• Pro: se ve bien
• Con: los caracteres unicode y, por lo tanto, todo el significado podría perderse en la cadena de herramientas (editor, formateador de código, control de versiones, compilador anterior)

¿Qué tan grande es el riesgo para ti? ¿La ganancia supera el riesgo?

En algún momento en un futuro no muy lejano, todos utilizaremos editores de texto / IDEs / navegadores web que facilitan la escritura de texto de edición, incluidos los caracteres griegos clásicos, etc. (O tal vez todos hemos aprendido a usar este "oculto" "funcionalidad en las herramientas que usamos actualmente ...)

Pero hasta que eso suceda, los caracteres no ASCII en el código fuente del programa serían difíciles de manejar para muchos programadores y, por lo tanto, es una mala idea si está escribiendo aplicaciones que podrían necesitar ser mantenidas por otra persona.

(Por cierto, la razón por la que puede tener caracteres griegos pero no signos de raíz cuadrada en los identificadores de Python es simple. Los caracteres griegos se clasifican como letras Unicode, pero el signo de raíz cuadrada no es una letra; consulte http://www.python.org / dev / peps / pep-3131 / )

No dijo qué idioma / compilador está utilizando, pero generalmente la regla para los nombres de variables es que deben comenzar con un carácter alfabético o guión bajo y contener solo caracteres alfanuméricos y guiones bajos. Un Unicode √ no se consideraría alfanumérico, ya que es un símbolo matemático en lugar de una letra. Sin embargo, σ podría ser (ya que está en el alfabeto griego) y á probablemente se consideraría alfanumérico.

Publiqué el mismo tipo de pregunta en StackOverflow

Definitivamente creo que vale la pena usar Unicode en problemas pesados ​​relacionados con las matemáticas, porque hace posible leer la fórmula directamente, lo cual es imposible con ASCII simple.

Imagine una sesión de depuración: por supuesto, siempre puede escribir a mano la fórmula que el código debe calcular para ver si es correcta. Pero el noventa por ciento de las veces, no te molestarás y el error puede permanecer oculto durante mucho tiempo. Y nadie está dispuesto a mirar esta fórmula ASCII simple de 7 líneas. Por supuesto, usar unicode no es tan bueno como una fórmula renderizada por texto, pero es mucho mejor.

La alternativa de usar nombres descriptivos largos no es viable porque en matemáticas, si el identificador no es corto, la fórmula se verá aún más complicada (¿por qué crees que las personas, alrededor del siglo XVIII, comenzaron a reemplazar "más" por "+" y "menos" por "-"?).

Personalmente, también usaría algunos subíndices y superíndices (solo los copio y pego desde esta página ). Por ejemplo: (tenía Python permitido √ como identificador)

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

Donde utilicé superíndices porque no hay un subíndice equivalente en Unicode. (Desafortunadamente, el conjunto de caracteres de subíndice Unicode es muy limitado. Espero que algún día, la suscripción en Unicode se considere como signos diacríticos, es decir, una combinación de un carácter para subíndice y otro carácter para la letra con subíndice)

Una última cosa, creo que esta conversación sobre el uso de caracteres no ASCII es principalmente parcial, porque muchos programadores nunca tratan con "notaciones matemáticas intensivas en fórmulas". Entonces piensan que esta pregunta no es tan importante, porque nunca experimentaron una porción significativa de código que requeriría el uso de identificadores no ASCII. Si usted es uno de ellos (y lo era hasta hace poco), considere esto: suponga que la letra "a" no es parte de ASCII. Entonces tendrá una idea bastante buena del problema de no tener ninguna letra griega, subíndice, superíndice al calcular fórmulas matemáticas no triviales.

¿Es este código solo para su proyecto personal? Si es así, enloquece, usa lo que quieras.

¿Este código está destinado a que otros lo usen? es decir, y una aplicación de código abierto de algún tipo? Si es así, es probable que solo esté buscando problemas porque diferentes programadores usan diferentes editores, y no puede estar seguro de que todos los editores admitirán Unicode correctamente. Además, no todos los shells de comandos lo mostrarán correctamente cuando el archivo de código fuente esté tecleado / cat'd, y puede tener problemas si necesita mostrarlo en html.

Personalmente, estoy motivado para considerar los lenguajes de programación como una herramienta para los matemáticos en este contexto, ya que en realidad no uso matemáticas que se vean así en mi vida. : D Y claro, ¿por qué no usar ɛ o σ o lo que sea? En ese contexto, en realidad es más legible.

(Aunque, debo decir, mi preferencia sería admitir números de superíndice como llamadas de método directo, no nombres de variables. Por ejemplo, 2² = 2 ** 2 = 4, etc.)

¿Qué demonios es σ, lo es W, lo es ε, cy lo que es γ?
Debe nombrar sus variables de una manera que explique cuál es su propósito.
Yo personalmente golpeaba a cualquiera que dejara el Unicode o la versión ASCII para que yo mantuviera, aunque la versión ASCII es mejor.

Lo que es malo es llamar variables σo so sigmao valueo var1, porque esto no transmite ninguna información.

Suponiendo que escriba su código en inglés (como creo que debería hacerlo donde sea que esté), ASCII debería ser suficiente para darles a sus variables nombres significativos, por lo que no hay necesidad real de Unicode.

Para nombres de variables con orígenes matemáticos bien conocidos, esto es absolutamente aceptable, incluso preferido. Pero si alguna vez espera distribuir el código, debe colocar estos valores en un módulo, clase, etc. para que el autocompletado IDE pueda manejar "escribir" los caracteres extraños.

Usar √ o ² en un identificador, no tanto.