c++ - variáveis - o que é o uri judge




Por que os nomes das variáveis não podem começar com números? (16)

Eu estava trabalhando com um novo desenvolvedor de C ++ há algum tempo quando ele fez a pergunta: "Por que os nomes de variáveis ​​não podem começar com números?"

Eu não consegui chegar a uma resposta, exceto que alguns números podem ter texto neles (123456L, 123456U) e isso não seria possível se os compiladores estivessem pensando que tudo com alguma quantidade de caracteres alfa era um nome de variável.

Essa foi a resposta certa? Há mais alguma razão?

string 2BeOrNot2Be = "that is the question"; // Why won't this compile?

É fácil para um compilador identificar uma variável usando ASCII na localização da memória em vez de numero.


É provável que seja uma decisão que veio por algumas razões, quando você está analisando o token, você só tem que olhar para o primeiro caractere para determinar se é um identificador ou literal e então enviá-lo para a função correta para processamento. Então, isso é uma otimização de desempenho.

A outra opção seria verificar se não é um literal e deixar o domínio de identificadores como o universo menos os literais. Mas para fazer isso você teria que examinar cada caractere de cada token para saber como classificá-lo.

Há também as implicações estilísticas que os identificadores devem ser mnemônicos, de modo que as palavras são muito mais fáceis de lembrar do que os números. Quando muitas das línguas originais estavam sendo escritas, estabelecendo os estilos para as próximas décadas, eles não estavam pensando em substituir "2" por "to".


A restrição é arbitrária. Vários Lisps permitem nomes de símbolos para começar com numerais.


A variável pode ser considerada como um valor também durante o tempo de compilação pelo compilador para que o valor possa chamar o valor novamente e novamente de forma recursiva


Como várias pessoas notaram, há muita bagagem histórica sobre formatos válidos para nomes de variáveis. E os designers de idiomas são sempre influenciados pelo que sabem quando criam novas linguagens.

Dito isso, praticamente todo o tempo em que uma linguagem não permite nomes de variáveis ​​começar com números é porque essas são as regras do design da linguagem. Muitas vezes é porque uma regra tão simples torna a análise e a adaptação da linguagem muito mais fáceis. Nem todos os designers de idiomas sabem que essa é a verdadeira razão, no entanto. As ferramentas modernas de lexing ajudam, porque se você tentar defini-lo como permissível, elas lhe darão conflitos de análise.

OTOH, se o seu idioma tiver um caractere exclusivo para identificar os nomes das variáveis, é possível configurá-los para começar com um número. Variações de regras semelhantes também podem ser usadas para permitir espaços em nomes de variáveis. Mas a linguagem resultante provavelmente não se assemelhará muito a nenhuma linguagem convencional popular.

Para um exemplo de uma linguagem de templates HTML bastante simples que permite que variáveis ​​comecem com números e tenham espaços embutidos, veja o Qompose .


Compiladores / analisadores / analisadores lexicais foi há muito, muito tempo atrás para mim, mas acho que lembro de haver dificuldade em determinar inequivocamente se um caractere numérico na unidade de compilação representava um literal ou um identificador.

Idiomas onde o espaço é insignificante (como o ALGOL e o FORTRAN original, se bem me lembro) não puderam aceitar números para iniciar identificadores por esse motivo.

Isso vai de volta - antes de notações especiais para indicar armazenamento ou base numérica.


Eu acho que a resposta simples é que pode, a restrição é baseada em linguagem. Em C ++ e em muitos outros, não é possível porque a linguagem não suporta isso. Não está embutido nas regras para permitir isso.

A questão é semelhante a perguntar por que o rei não pode mover quatro espaços de cada vez no xadrez? É porque no xadrez isso é um movimento ilegal. Pode em outro jogo com certeza. Depende apenas das regras que estão sendo jogadas.


Não pode haver nada de errado com isso quando se trata de declarar variável.mas existe alguma ambiguidade quando ele tenta usar essa variável em algum outro lugar como este:

vamos 1 = "Olá mundo!" impressão (1) impressão (1)

imprimir é um método genérico que aceita todos os tipos de variáveis. Portanto, nesse compilador de situação, não se sabe a que (1) o programador se refere: o valor inteiro 1 ou o valor 1 que armazena um valor de string. talvez seja melhor para o compilador nessa situação permitir definir algo assim, mas ao tentar usar esse material ambíguo, traga um erro com a capacidade de correção para como corrigir esse erro e limpar essa ambigüidade.


O COBOL permite que as variáveis ​​iniciem com um dígito.


O compilador tem 7 fases da seguinte forma:

  1. Análise lexical
  2. Análise de Sintaxe
  3. Análise Semântica
  4. Geração de Código Intermediário
  5. Otimização de Código
  6. Geração de Código
  7. Tabela de Símbolos

O retrocesso é evitado na fase de análise léxica durante a compilação do trecho de código. A variável como Apple, o compilador saberá seu identificador imediatamente quando encontrar o caractere de letra 'A' na fase de análise léxica. No entanto, uma variável como 123apple, o compilador não será capaz de decidir se é um número ou identificador até atingir 'a' e precisar de backtracking para ir na fase de análise lexical para identificar que é uma variável. Mas não é suportado no compilador.

Quando você está analisando o token, você só tem que olhar para o primeiro caractere para determinar se é um identificador ou literal e então enviá-lo para a função correta para processamento. Então, isso é uma otimização de desempenho.


Originalmente, era simplesmente porque é mais fácil lembrar (você pode dar mais significado) nomes de variáveis ​​como strings em vez de números, embora números possam ser incluídos na string para melhorar o significado da string ou permitir o uso do mesmo nome de variável, mas designá-lo como tendo um significado ou contexto separado, mas próximo. Por exemplo, loop1, loop2 etc sempre informavam que você estava em um loop e / ou loop 2 era um loop dentro de loop1. Qual você prefere (tem mais significado) como variável: address ou 1121298? Qual é mais fácil de lembrar? No entanto, se a linguagem usa algo para denotar que não apenas texto ou números (como o endereço $ in $) ela realmente não deve fazer diferença, pois isso diria ao compilador que o que segue é para ser tratado como uma variável ( nesse caso). De qualquer forma, tudo se resume ao que os projetistas de idiomas querem usar como regras para sua linguagem.


Os nomes das variáveis ​​não podem começar com um dígito, porque podem causar alguns problemas, como abaixo:

int a = 2;
int 2 = 5;
int c = 2 * a; 

qual é o valor de c? é 4 ou é 10!

outro exemplo:

float 5 = 25;
float b = 5.5;

é o primeiro 5 um número, ou é um objeto (. operador) Há um problema semelhante com o segundo 5.

Talvez haja outras razões. Portanto, não devemos usar nenhum dígito no início do nome de uma variável.


Porque se você permitisse que a palavra-chave e o identificador começassem com caracteres numéricos, o léxico (parte do compilador) não poderia diferenciar prontamente entre o início de um literal numérico e uma palavra-chave sem ficar muito mais complicado (e mais lento).


Porque, então, uma sequência de dígitos seria um identificador válido, além de um número válido.

int 17 = 497;
int 42 = 6 * 9;
String 1111 = "Totally text";

Suponha que você permitiu que os nomes dos símbolos começassem com números. Agora, suponha que você queira nomear uma variável 12345foobar. Como você diferenciaria isso de 12345? Na verdade não é muito difícil fazer com uma expressão regular. O problema é na verdade um de desempenho. Eu não posso realmente explicar por que isso está em grande detalhe, mas isso se resume essencialmente ao fato de que diferenciar 12345foobar de 12345 exige backtracking. Isso torna a expressão regular não determinística.

Há uma explicação muito melhor disso here .


Um dos principais problemas sobre o relaxamento das convenções sintáticas é que ele introduz a dissonância cognitiva no processo de codificação. Como você pensa sobre o seu código pode ser profundamente influenciado pela falta de clareza que isso introduziria.

Não foi Dykstra quem disse que "o aspecto mais importante de qualquer ferramenta é seu efeito sobre o usuário"?





variable-names