É ruim usar caracteres Unicode em nomes de variáveis? [fechadas]


82

Recentemente, tentei implementar um algoritmo de classificação, AllegSkill, no Python 3.

Aqui está a aparência da matemática:

texto alternativo

Não mesmo.

Isto é o que eu escrevi:

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

Na verdade, pensei que era lamentável que o Python 3 não aceitasse ou ²como nomes de variáveis.

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

Estou maluco? Eu deveria ter recorrido a uma versão apenas ASCII? Por quê? Uma única versão ASCII acima não seria mais difícil de validar para equivalência com as fórmulas?

Veja bem, eu entendo que alguns glifos Unicode se parecem muito e outros como (ou é isso ▗▖) ou ╦ simplesmente não fazem sentido no código escrito. No entanto, esse não é o caso de matemática ou glifos de seta.


Por solicitação, a versão somente ASCII seria algo como:

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

... por cada etapa do algoritmo.


58
Isso é insano, completamente ilegível e indescritivelmente legal.
Dominique McDonnell


3
Acho muito bom que o Python não aceite operações aritméticas como variáveis. Um sinal de raiz quadrada deve denotar a operação de obter uma raiz quadrada e não deve ser uma variável.
Thornley

4
@ David, não existe essa distinção em Python. Na verdade, sqrt = lambda x: x**.5me recebe uma função (mais precisamente, um resgatável): sqrt(2) => 1.41421356237.
badp

4
OutputStream.🚽;

Respostas:


54

Eu sinto fortemente que apenas substituir σpor sou sigmaseria estúpido, na fronteira com morte cerebral.

Qual é o ganho potencial? Bem vamos ver …

  • Melhora a legibilidade? Não, nem um pouco. Se assim fosse, a fórmula original teria, sem dúvida, usado também letras latinas.

  • Melhora a capacidade de escrita? À primeira vista, sim. Mas no segundo, não. Porque essa fórmula nunca vai mudar (bem, "nunca"). Normalmente, não há necessidade de alterar o código nem estendê-lo usando essas variáveis. Portanto, a gravabilidade é - apenas desta vez - não um problema.

Pessoalmente, acho que as linguagens de programação têm uma vantagem sobre as fórmulas matemáticas: você pode usar identificadores significativos e expressivos. Em matemática, normalmente não é esse o caso, por isso recorremos a variáveis ​​de uma letra, ocasionalmente tornando-as gregas.

Mas o grego não é o problema. Os identificadores não descritivos de uma letra são.

Assim, ou manter a notação original ... afinal, se a linguagem de programação faz suporte a Unicode em identificadores, então não há nenhuma barreira técnica. Ou use identificadores significativos. Não substitua apenas os glifos gregos por glifos latinos. Ou árabe, ou hindi.


3
Algumas ferramentas não conseguem ler caracteres unicode, mesmo que a linguagem de programação suporte seu uso. Eu não chamaria de decisão com morte cerebral usar nomes de variáveis ​​não unicode, e isso ainda é válido 2,5 anos após a sua postagem.
Gary S. Weaver

44
@ Gary “Algumas ferramentas não conseguem ler Unicode” - então mude as ferramentas, elas são uma porcaria. Desculpe, é 2013 e não tenho simpatia e ainda menos paciência por essas ferramentas. O fornecimento excessivo de ferramentas com defeito impede o progresso.
11133 Konrad Rudolph

3
@KonradRudolph Meu argumento é que algumas ferramentas não suportam e não podem suportar o Unicode por qualquer motivo, portanto, "alterar as ferramentas" nem sempre é a resposta certa. Concordo que o Unicode é bom e as ferramentas devem entendê-lo, mas isso nem sempre é uma opção.

3
@ John Eu mantenho que “mudar as ferramentas” é uma resposta apropriada. Seu exemplo, em particular, ilustra esse caso: os .propertiesarquivos Java são fáceis de analisar. Se você realmente trabalhou com uma cadeia de ferramentas que, apoiada em .propertiesarquivos, não suportava Unicode, é perfeitamente razoável descartar a cadeia de ferramentas (e substitua-a você mesmo, encontre uma alternativa ou, na pior das hipóteses, comissione uma) ) Claro que isso não se aplica aos sistemas legados. Porém, para sistemas legados, nenhuma das considerações sobre melhores práticas se aplica.
Konrad Rudolph

8
Esses problemas de "intercâmbio" de que você fala parecem ser principalmente o problema dos desenvolvedores de Java e Windows. A maior parte do mundo Linux padronizou o UTF-8 há mais de uma década. Definitivamente, é um problema de cadeia de ferramentas. Pare de usar ferramentas ruins.
rich remer

33

Pessoalmente, eu odiaria ver o código onde tenho que abrir o mapa de caracteres para digitá-lo novamente. Embora o unicode corresponda intimamente ao conteúdo do algoritmo, está prejudicando a legibilidade e a capacidade de edição. Alguns editores podem até não ter uma fonte que suporte esse caractere.

Que tal uma alternativa e apenas ter em cima //µ = ue escrever tudo em ASCII?


14
A propósito, não assuma que todos os teclados exponham confortavelmente as teclas de codificação padrão. Meu layout de teclado precisa de três teclas para digitar {e }(o que falha em ttys btw) e não existe completamente ... `e ~como nenhum script do Bash não exigiria que eu usasse um mapa de caracteres, se eu não estivesse usando um mapa de teclas personalizado? :)
badp

4
Eu instalei um teclado grego ao lado do meu nativo e posso alternar entre aqueles com um toque de tecla. Isso é útil quando se fala de matemática em mensagens instantâneas / email ... e eu já pensei em usá-lo em scripts python.
Liori

18
Ugh. Apenas substituindo as letras gregas pelas comuns? Não há ganho algum. Use nomes de variáveis ​​significativos ou cole os nomes do papel. Não há razão para ser criativo.
amigos estão dizendo sobre Konrad Rudolph

12
Apenas não misture µ e μ ... #
28351

4
Editores razoáveis ​​têm métodos de entrada razoáveis ​​para Unicode, o que facilita a edição de códigos como este. Por exemplo, o Emacs suporta (entre outras coisas) o TeXe rfc1345. TeXé exatamente o que parece; permite digitar \sigmapara σe \topara . rfc1345fornece algumas combinações como &s*para σe &->para . Como regra geral, não me preocupo em acomodar programadores usando editores menos capazes que o Emacs.
Tikhon Jelvis 3/12/12

31

Esse argumento pressupõe que você não tenha problemas ao digitar unicodes nem ler letras gregas

Aqui está o argumento: você gostaria de pi ou circular_ratio?

Nesse caso, eu preferiria pi a circular_ratio porque aprendi sobre pi desde que eu estava na escola e posso esperar que a definição de pi esteja bem enraizada em todos os programadores que se prezam. Portanto, eu não me importaria de digitar π para significar circular_ratio.

No entanto, que tal

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

Para mim, ambas as versões são igualmente opaco, tal como piou πseja, exceto eu não aprendi esta fórmula na grade escolar. winner_sigmae Wwinnão significa nada para mim ou para ninguém que esteja lendo o código, e o uso de nenhum deles σwnão o torna melhor.

Portanto, usar nomes descritivos, por exemplo total_score, winning_ratioetc, aumentaria a legibilidade muito melhor do que usar nomes ascii que apenas pronunciam letras gregas . O problema não é que não consigo ler letras gregas, mas não consigo associar os caracteres (gregos ou não) a um "significado" da variável.

Você certamente compreendeu o problema sozinho quando comentou: You should have seen the paper. It's just eight pages.... O problema é que, se você basear sua nomeação de variável em um documento, que escolhe nomes de letra única por concisão em vez de legibilidade (independentemente de serem gregos), as pessoas precisariam ler o jornal para poder associar as letras a um "significado"; isso significa que você está colocando uma barreira artificial para que as pessoas possam entender seu código, e isso é sempre uma coisa ruim.

Mesmo quando você mora em um mundo apenas ASCII, ambos a * b / 2e alpha * beta / 2são uma representação igualmente opaca da height * base / 2fórmula da área do triângulo. A ilegibilidade do uso de variáveis ​​de letra única cresce exponencialmente à medida que a fórmula cresce em complexidade, e a fórmula AllegSkill certamente não é uma fórmula trivial.

A variável de letras únicas é aceitável apenas como um contador de loop simples, sejam elas letras gregas ou ascii, não me importo; nenhuma outra variável deve consistir apenas em uma única letra. Não me importo se você usa letras gregas para seus nomes, mas, quando usá-las, verifique se posso associá-los a um "significado" sem precisar ler um artigo arbitrário em outro lugar.

Quando estava na escola primária, eu definitivamente não me importaria de ver expressões matemáticas usando símbolos como: +, -, ×, ÷, para aritmética básica e √ () seria uma função de raiz quadrada. Depois que me formei na escola, não me importaria com a adição de novos símbolos brilhantes: ∫ para integração. Observe a tendência, todos esses são operadores. Operadores são muito mais usados ​​do que nomes de variáveis, mas são menos reutilizados para um significado totalmente diferente (no caso em que matemáticos reutilizam operadores, o novo significado ainda mantém algumas propriedades básicas do significado antigo; esse não é o caso de ao reutilizar nomes de variáveis).

Concluindo, não, não é ruim usar caracteres Unicode para nomes de variáveis; no entanto, é sempre ruim usar nomes de letra única para nomes de variáveis, e ter permissão para usar nomes Unicode não é uma licença para usar nomes de variáveis ​​de letra única.


9
Para ser honesto, as fórmulas aqui não fazem mais sentido, mesmo que eu use em error_on_measured_skill_with_99th_percent_confidencevez de sigma.
badp

4
@badp: Nomes longos! = Bons nomes. No entanto, há ocasiões em que é impossível escolher um bom nome (por exemplo, quando você entende apenas a fórmula, mas não compreende completamente o que cada parte da fórmula faz (o que requer um nível de compreensão totalmente diferente)), então, nesse caso, a segunda melhor alternativa é encobrir sua bunda com alguns comentários (melhor do que enviá-los para um jornal externo). Adicione um dicionário de dados que explique a que os nomes de variáveis ​​se referem, por exemplo // σw = skill level measurement error, etc.
Lie Ryan

1
@badp: Para ser sincero, com apenas essa informação, esse sigma se refere a algum fator de falsificação (por assim dizer), me dá um entendimento um pouco melhor da fórmula do que o que o sigma me impressiona. Quando a fórmula é difícil de entender, para começar, você não deseja adicionar mais opacidade a ela.
Lie Ryan

2
Sim. Este. Infelizmente, eu ignorei isso ao escrever minha resposta.
amigos estão dizendo sobre Konrad Rudolph

3
Bem, qualquer pessoa que trabalhe em algo relacionado à estatística sabe que σ significa "desvio padrão". É um símbolo padrão muito conhecido nesse domínio.
TRiG 21/12/12

14

Você entende o código? Todo mundo que precisa ler? Nesse caso, não há problema.

Pessoalmente, ficaria feliz em ver a parte de trás do código-fonte somente ASCII.


Feito. (Presumo que a última linha você estava pedindo para ver a versão somente do código ASCII?) [] (Http: // ~)
badp

4
@badp: Não, eu estava pedindo para ver a morte do código somente ASCII.

até que você começar a ver o que acontece com arquivos fonte Unicode quando aterram em um sistema Windows 1252 ...

1
@ Thorbjørn: se eles contiverem a lista técnica, espero que nada aconteça.

9

Sim, você está maluco. Eu pessoalmente referenciaria o número do artigo e da fórmula em um comentário e escreveria tudo em ASCII direto. Então, qualquer pessoa interessada seria capaz de correlacionar o código e a fórmula.


5
Foi difícil para mim para garantir que o código e a fórmula combinada , em primeiro lugar ...
badp

10
@Paul: felizmente, o Unicode tem> 10 anos para que a objeção tenha sido resolvida. E embora não haja um vencedor claro entre as diferentes UTFs, isso não é um problema: não deveria haver um. Diferenciá-los é trivial para o software.
Konrad Rudolph

1
@ Konrad: Eu quero dizer daqui a 10 anos agora . Um bom número de programas ainda não suporta Unicode. Além disso, eu discordo de sua afirmação - Não é trivial escrever uma rotina reversa genérica que lide com todos os 3 utfs. É preciso haver um vencedor claro. Não faz sentido dar suporte a três UTFs diferentes (não vamos considerar as outras páginas de código ainda existentes).
Paul Nathan

3
@ Paul: Quantas vezes você precisa escrever uma "rotina reversa genérica"? As três UTFs servem a propósitos diferentes, e acho que você nunca conseguirá o seu desejo de consolidação.
Dean Harding

7
@ Paul: estragar esses programas. Existem bons editores suficientes que sabem como lidar com Unicode. Se algum editor ainda não entrou na onda, deixe a seleção econômica cuidar disso. E, como Dean disse, as UTFs servem a propósitos diferentes. É bom que eles existam. E eu não vejo o ponto em suas múltiplas rotinas reversas. Você só precisa escrevê-lo uma vez (ignorando os formulários de normalização por enquanto): para pontos de código, não para UTFs individuais.
Konrad Rudolph

5

Eu diria que usar nomes de variáveis ​​Unicode é uma má idéia por dois motivos:

  1. Eles são uma PITA para digitar.

  2. Eles geralmente parecem quase o mesmo que as letras em inglês. Esta é a mesma razão pela qual eu odeio ver letras gregas em notação matemática. Tente diferenciar rho da p. Não é fácil.


6
Depende do que você está usando para digitá-los.
Endolith 26/05

4

Neste caso, uma fórmula matemática complexa, eu diria que vá em frente.

Posso dizer que, em 20 anos, nunca tive que codificar algo que essas letras gregas e complexas mantêm perto da matemática original. Se você não consegue entender, não deve mantê-lo.

Dizendo que, se eu tiver que manter µ e σ no código padrão do pântano que você me legou, vou descobrir onde você mora ...


3
  • Pro: parece bom
  • Con: os caracteres unicode e, portanto, todo o significado pode se perder na cadeia de ferramentas (editor, formatador de código, controle de versão, compilador antigo)

Qual é o risco para você? O ganho supera o risco?


2
Cadeia de ferramentas? Que cadeia de ferramentas?
Bad1 de

2
Editor, formatador de código, controle de versão, compilador antigo. Todas as ferramentas e pessoas que tocam no seu arquivo. Eu tive uma experiência ruim com ferramentas que mexem com arquivos unicode, YMMV.
precisa saber é o seguinte

2

Em algum momento em um futuro não muito distante, todos usaremos editores de texto / IDEs / navegadores da Web que facilitam a escrita de texto de edição, incluindo caracteres gregos clássicos etc. (ou talvez todos aprendemos a usar isso " "funcionalidade nas ferramentas que usamos atualmente ...)

Mas, até que isso aconteça, seria difícil para muitos programadores caracteres não ASCII no código-fonte do programa e, portanto, é uma má idéia se você estiver escrevendo aplicativos que talvez precisem ser mantidos por outra pessoa.

(Aliás, o motivo pelo qual você pode ter caracteres gregos, mas não sinais de raiz quadrada em identificadores Python, é simples. Os caracteres gregos são classificados como Letras Unicode, mas o sinal de raiz quadrada não é uma letra; consulte http://www.python.org / dev / peps / pep-3131 / )


Eu acho que seria uma ótima idéia criar um IME que pudesse traduzir caracteres para usuários que não podem inseri-los diretamente.
precisa saber é o seguinte

Sim, mais ou menos quando mudarmos para o DVORAK. :(
badp

1
O @AndrejaKo Linux possui um IME que aceita comandos no estilo LaTeX - ou seja, você digita \mue insere µ.
badp

@badp Muito obrigado! Vou tentar na próxima vez que inicializar!
precisa saber é o seguinte

O Emacs suporta vários métodos de entrada interessantes que facilitam a digitação de símbolos Unicode. (Incluindo um TeX que é o que eu uso.) O Emacs é dificilmente futurista. (Ele é incrível, é claro.)
Tikhon Jelvis

2

Você não disse qual idioma / compilador está usando, mas geralmente a regra para nomes de variáveis ​​é que eles devem começar com um caractere alfabético ou sublinhado e conter apenas alfanuméricos e sublinhados. Um Unicode √ não seria considerado alfanumérico, pois é um símbolo matemático em vez de uma letra. No entanto, σ pode ser (já que está no alfabeto grego) e á provavelmente seria considerado alfanumérico.


1

Publiquei o mesmo tipo de pergunta no StackOverflow

Definitivamente, acho que vale a pena usar o unicode em problemas pesados ​​de matemática, porque torna possível ler a fórmula diretamente, o que é impossível com o ASCII simples.

Imagine uma sessão de depuração: é claro que você sempre pode escrever à mão a fórmula que o código deve calcular para verificar se está correta. Mas noventa por cento das vezes, você não se incomoda e o bug pode permanecer oculto por um longo e longo período de tempo. E ninguém nunca está disposto a olhar para essa fórmula ASCII simples e de 7 linhas. Obviamente, usar unicode não é tão bom quanto uma fórmula renderizada com tex, mas é muito melhor.

A alternativa de usar nomes descritivos longos não é viável porque, em matemática, se o identificador não for curto, a fórmula parecerá ainda mais complicada (por que você acha que as pessoas, por volta do século XVIII, começaram a substituir "mais" por "+" e "menos" por "-"?).

Pessoalmente, eu também usaria alguns subscritos e sobrescritos (eu apenas os copio e colo desta página ). Por exemplo: (python permitiu √ como um identificador)

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

Onde eu usei sobrescritos porque não há equivalente subscrito no unicode. (Infelizmente, o conjunto de caracteres de subscrito unicode é muito limitado. Espero que um dia a assinatura em unicode seja considerada diacrítica, ou seja, uma combinação de um caractere para subscrito e outro caractere para a letra assinada)

Uma última coisa, acho que essa conversa sobre o uso de caracteres não ASCII é principalmente tendenciosa, porque muitos programadores nunca lidam com "notações matemáticas intensivas em fórmulas". Portanto, eles acham que essa pergunta não é tão importante, porque nunca experimentaram uma parte significativa do código que exigiria o uso de identificadores não ASCII. Se você é um deles (e eu era até recentemente), considere o seguinte: suponha que a letra "a" não faça parte do ASCII. Então você terá uma boa idéia do problema de não ter letras gregas, subscritos ou sobrescritos ao calcular fórmulas matemáticas não triviais.


0

Esse código é apenas para o seu projeto pessoal? Nesse caso, enlouqueça, use o que quiser.

Esse código é destinado a outras pessoas? ou seja, e aplicativo de código aberto de algum tipo? Nesse caso, é provável que você esteja apenas procurando problemas, porque diferentes programadores usam editores diferentes, e você não pode ter certeza de que todos os editores suportarão o unicode corretamente. Além disso, nem todos os shells de comando o mostrarão corretamente quando o arquivo de código-fonte for digitado / cat'd, e você poderá encontrar problemas se precisar exibi-lo em html.


0

pessoalmente, estou motivado a considerar as linguagens de programação como uma ferramenta para os matemáticos nesse contexto, pois na verdade não uso matemática que se pareça com isso na minha vida. : D E claro, por que não usar ɛ ou σ ou o que quer que seja - nesse contexto, é realmente mais legível.

(Embora, devo dizer, minha preferência seria suportar números sobrescritos como chamadas diretas ao método, não nomes de variáveis. Por exemplo, 2² = 2 ** 2 = 4, etc.)


-2

Que diabo é σ, o que é W, o que é ε, ceo que é γ?
Você deve nomear suas variáveis ​​de uma maneira que explique qual é o objetivo delas.
Eu pessoalmente espancaria qualquer um que deixasse o Unicode ou a versão ASCII para eu manter, embora a versão ASCII seja melhor.

O que é mau é chamar variáveis σou sou sigmaou valueou var1, porque isso não transmite nenhuma informação.

Supondo que você escreva seu código em inglês (como acredito que seja de onde você for), o ASCII deve ser suficiente para fornecer nomes significativos às suas variáveis, para que não haja uma necessidade real de Unicode.


2
e se ele fizesse uma cópia / pasta do papel e o tornasse parte de seu código-fonte como um comentário, apesar dos nomes das variáveis ​​de um caractere?
Brian

19
Muitos desses nomes de variáveis ​​têm significados fortes para aqueles familiarizados com o domínio do problema. Para alguém familiarizado com o domínio, nomes em inglês podem ser menos legíveis do que nomes como sigma ou rho.
#

3
Receio que algo como rank_error_with_99_pct_confidenceseja um pouco longo demais para isso e não facilite a compreensão das fórmulas. AllegSkill / TrueSkill chama esses sigma, então eu acredito que é perfeitamente aceitável da minha parte manter o nome específico de domínio que eles têm.
badp

3
@badp: bons nomes são concisos e descritivos; mas não precisa ser totalmente descritivo. Para o seu sigma, é perfeitamente bom usar rank_errore colocar os detalhes extras sobre 99% de confiança na documentação / comentário em algum lugar.
Lie Ryan

1
@dsimcha: Eu acho que aqueles familiarizados com um domínio específico são significativamente mais raros do que aqueles que nunca ouviram falar dele. E acho que aqueles familiarizados com o domínio serão capazes de lidar com nomes comuns em inglês, enquanto aqueles que não estão familiarizados com ele serão completamente incapazes de entender o que está acontecendo se tudo for ofuscado pelas variáveis ​​gregas de uma letra.
#

-2

Para nomes de variáveis ​​com origens matemáticas conhecidas, isso é absolutamente aceitável - e até preferido. Mas se você espera distribuir o código, coloque esses valores em um módulo, classe etc. para que o preenchimento automático do IDE possa manipular a "digitação" dos caracteres estranhos.

Usando √ ou ² em um identificador - não muito.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.