Costumava haver muito boas razões para manter a instrução / registrar nomes curtos. Esses motivos não se aplicam mais, mas nomes curtos e criptografados ainda são muito comuns na programação de baixo nível.

Por que é isso? É apenas porque os velhos hábitos são difíceis de quebrar, ou existem melhores razões?

Por exemplo:

• Atmel ATMEGA32U2 (2010?): TIFR1(Em vez de TimerCounter1InterruptFlag), ICR1H(em vez de InputCapture1High), DDRB(em vez de DataDirectionPortB), etc.
• Conjunto de instruções .NET CLR (2002): bge.s(em vez de branch-if-greater-or-equal.short), etc.

Os nomes mais longos e não enigmáticos não são mais fáceis de trabalhar?

Ao responder e votar, considere o seguinte. Muitas das explicações possíveis sugeridas aqui se aplicam igualmente à programação de alto nível, e, no entanto, o consenso, em geral, é o de usar nomes não criptográficos que consistam em uma palavra ou duas (siglas comumente excluídas).

Além disso, se seu argumento principal é sobre espaço físico em um diagrama em papel , considere que isso absolutamente não se aplica à linguagem assembly ou CIL, além disso, eu apreciaria se você me mostrasse um diagrama em que nomes concisos se encaixam, mas nomes legíveis tornam o diagrama pior . Da experiência pessoal em uma empresa de semicondutores sem fábricas, os nomes legíveis se encaixam perfeitamente e resultam em diagramas mais legíveis.

Qual é o principal aspecto da programação de baixo nível, em oposição às linguagens de alto nível, que torna os nomes criptográficos concisos desejáveis ​​na programação de baixo nível, mas não de alto nível?

A razão pela qual o software usa esses nomes é porque as planilhas de dados os usam. Como o código nesse nível é muito difícil de entender sem a folha de dados, criar nomes de variáveis ​​que você não pode pesquisar é extremamente inútil.

Isso levanta a questão de por que as planilhas de dados usam nomes abreviados. Provavelmente porque você geralmente precisa apresentar os nomes em tabelas como esta, onde você não tem espaço para identificadores de 25 caracteres:

Além disso, coisas como esquemas, diagramas de pinos e serigrafias PCB geralmente são muito limitadas por espaço.

Lei de Zipf

Você mesmo pode observar, olhando para este texto, que o comprimento das palavras e a frequência de uso são, em geral, inversamente relacionadas. Palavras que são usadas com muita freqüência, como it, a, but, you, e andsão muito curtos, enquanto palavras que são usadas menos frequentemente gosto observe, comprehensione verbositysão mais longos. Essa relação observada entre frequência e duração é chamada Lei de Zipf .

O número de instruções no conjunto de instruções para um determinado microprocessador geralmente é de dezenas ou centenas. Por exemplo, o conjunto de instruções do Atmel AVR parece conter cerca de cem instruções distintas (eu não contei), mas muitas delas são variações de um tema comum e têm mnemônicas muito semelhantes. Por exemplo, as instruções de multiplicação incluem MUL, MULS, MULSU, FMUL, FMULS e FMULSU. Você não precisa olhar a lista de instruções por muito tempo antes de ter a idéia geral de que as instruções que começam com "BR" são ramificações, as instruções que começam com "LD" são carregadas etc. O mesmo se aplica às variáveis: até processadores complexos fornecem apenas um número limitado de locais para armazenar valores: registros de condição, registros de uso geral, etc.

Como existem poucas instruções e como os nomes longos demoram mais para serem lidos, faz sentido dar nomes abreviados. Por outro lado, linguagens de nível superior permitem que os programadores criem um grande número de funções, métodos, classes, variáveis ​​e assim por diante. Cada uma delas será usada com muito menos frequência do que a maioria das instruções de montagem e nomes mais descritivos e longos são cada vez mais importantes para fornecer aos leitores (e escritores) informações suficientes para entender o que são e o que fazem.

Além disso, conjuntos de instruções para diferentes processadores geralmente usam nomes semelhantes para operações semelhantes. A maioria dos conjuntos de instruções inclui operações para ADD, MUL, SUB, LD, ST, BR, NOP e, se eles não usam esses nomes exatos, geralmente usam nomes muito próximos. Depois de aprender os mnemônicos para um conjunto de instruções, não demora muito para se adaptar aos conjuntos de instruções para outros dispositivos. Então nomes que podem parecer "enigmática" para que você está prestes tão familiar como palavras como and, ore notpara os programadores que são hábeis na arte de programação de baixo nível. Eu acho que a maioria das pessoas que trabalha no nível de montagem diria que aprender a ler o código não é um dos maiores desafios da programação de baixo nível.

Em geral

A qualidade da nomeação não é apenas ter nomes descritivos, mas também considerar outros aspectos, o que leva a recomendações como:

• quanto mais global o escopo, mais descritivo o nome deve ser
• quanto mais frequentemente é usado, mais curto deve ser o nome
• o mesmo nome deve ser usado em todos os contextos para a mesma coisa
• coisas diferentes devem ter nomes diferentes, mesmo que o contexto seja diferente
• variações devem ser facilmente detectadas
• ...

Observe que essas recomendações são conflitantes.

Mnemônicos de instruções

Como programador de linguagem assembly, usar short-branch-if-greater-or-equalfor bge.sme dá a mesma impressão que quando vejo, como um programador Algol fazendo geometria computacional, em SUBSTRACT THE-HORIZONTAL-COORDINATE-OF-THE-FIRST-POINT TO THE-HORIZONTAL-COORDINATE-OF-THE-SECOND-POINT GIVING THE-DIFFERENCES-OF-THE-COORDINATE-OF-THE-TWO-POINTSvez de dx := p2.x - p1.x. Só não posso concordar que os primeiros sejam mais legíveis nos contextos de que me importo.

Registrar nomes

Você escolhe o nome oficial da documentação. A documentação escolhe o nome do design. O design usa muitos formatos gráficos em que nomes longos não são adequados e a equipe de design convive com esses nomes por meses, se não anos. Por ambos os motivos, eles não usarão "Sinalizador de interrupção do contador do primeiro temporizador", eles o abreviarão em seu esquema e também quando falarem. Eles sabem disso e usam abreviações sistemáticas como TIFR1essas, para que haja menos chance de confusão. Um ponto aqui é que TIFR1não é uma abreviação aleatória, é o resultado de um esquema de nomeação.

Além dos motivos dos "velhos hábitos", o código legado que foi escrito há 30 anos e ainda está em uso é muito comum. Apesar do que algumas pessoas menos experientes pensam, refatorar esses sistemas para que pareçam bonitos tem um custo muito alto para um pequeno ganho e não é comercialmente viável.

Os sistemas embarcados que estão próximos ao hardware - e acessam os registros - tendem a usar rótulos iguais ou semelhantes aos usados ​​nas folhas de dados de Hardware, por boas razões. Se o registro é chamado XYZZY1 nas folhas de dados de hardware, faz sentido que a variável que representa é provável XYZZY1 ou se o programador estava tendo um bom dia, RegXYZZY1.

Quanto ao bge.s, é semelhante ao assembler - às poucas pessoas que precisam conhecê-lo, nomes mais longos são menos legíveis. Se você não consegue se convencer bge.se acha branch-if-greater-or-equal.shortque fará a diferença - você está apenas brincando com o CLR e não sabe disso.

A outra razão pela qual você verá nomes curtos de variáveis ​​deve-se à ampla disseminação de abreviações no domínio que o software está alvejando.

Em resumo - são esperados nomes abreviados de variáveis ​​abreviadas que refletem uma influência externa, como normas do setor e folhas de dados de hardware. Nomes abreviados de variáveis ​​abreviadas que são internas ao software são normalmente menos desejáveis.

Existem tantas idéias diferentes aqui. Eu não posso aceitar qualquer uma das respostas existentes como a resposta: em primeiro lugar, há uma probabilidade muitos fatores que contribuem para isso, e em segundo lugar, eu possivelmente não pode saber qual é o mais significativo.

Então, aqui está um resumo das respostas postadas por outras pessoas aqui. Estou postando isso como CW e minha intenção é eventualmente marcar como aceito. Por favor, edite se eu perdi alguma coisa. Tentei reformular cada ideia para expressá-la de forma concisa e clara.

Então, por que os identificadores curtos de criptografia são tão comuns na programação de baixo nível?

• Porque muitos deles são comuns o suficiente no respectivo domínio para garantir um nome muito curto. Isso piora a curva de aprendizado, mas é uma troca interessante, dada a frequência de uso.
• Porque geralmente há um pequeno conjunto de possibilidades que são corrigidas (o programador não pode adicionar ao conjunto).
• Porque a legibilidade é uma questão de hábito e prática. branch-if-greater-than-or-equal.shorté inicialmente mais legível do que bge.s, mas com alguma prática a situação se inverte.
• Como eles geralmente precisam ser digitados na íntegra, manualmente, porque os idiomas de baixo nível geralmente não vêm com IDEs poderosos que têm um bom preenchimento automático ou o a / c não é confiável.
• Por vezes, é desejável incluir muitas informações no identificador e um nome legível seria inaceitavelmente longo, mesmo para os padrões de alto nível.
• Porque é assim que os ambientes de baixo nível parecem historicamente. Quebrar o hábito requer esforço consciente, corre o risco de irritar aqueles que gostaram dos velhos hábitos e deve ser justificado como válido. Seguir a maneira estabelecida é o "padrão".
• Porque muitos deles se originam em outros lugares, como esquemas e folhas de dados. Esses, por sua vez, são afetados por restrições de espaço.
• Porque as pessoas encarregadas de nomear as coisas nunca consideraram legibilidade, ou não percebem que estão criando um problema ou são preguiçosas.
• Porque, em alguns casos, os nomes se tornaram parte de um protocolo para intercâmbio de dados, como o uso da linguagem assembly como uma representação intermediária por alguns compiladores.
• Porque esse estilo é instantaneamente reconhecível como de baixo nível e, portanto, parece legal para os geeks.

Pessoalmente, acho que algumas delas não contribuem de fato para as razões pelas quais um sistema recém-desenvolvido escolheria esse estilo de nomeação, mas achei que seria errado filtrar algumas idéias nesse tipo de resposta.

Vou jogar meu chapéu nessa bagunça.

Convenções e padrões de codificação de alto nível não são os mesmos que práticas e padrões de codificação de baixo nível. Infelizmente, a maioria desses são retenções de códigos legados e processos antigos de pensamento.

Alguns, no entanto, servem a um propósito. Claro que BranchGorgeousThan seria muito mais legível que o BGT , mas há uma convenção lá agora, é uma instrução e, como tal, ganhou um pouco de força nos últimos 30 anos de uso como padrão. Por que eles começaram com isso, provavelmente algum limite arbitrário de largura de caracteres para instruções, variáveis ​​e outras coisas; por que eles mantêm, é um padrão. Esse padrão é o mesmo que usar int como um identificador, seria mais legível usar Inteiro em todos os casos, mas é necessário para quem está programando há mais de algumas semanas ... não. Por quê? Porque é uma prática padrão.

Segundo, como eu disse no meu comentário, muitas das interrupções são nomeadas INTG1 e outros nomes enigmáticos, que também servem a um propósito. Nos diagramas de circuitos, NÃO é uma boa convenção nomear suas linhas e, de maneira verbal, desordenar o diagrama e prejudicar a legibilidade. Toda a verbosidade é tratada na documentação. E como todos os diagramas de fiação / circuito possuem esses nomes abreviados para linhas de interrupção, as próprias interrupções também recebem o mesmo nome para manter a consistência do projetista incorporado no diagrama de circuitos até o código para programá-lo.

Um designer tem algum controle sobre isso, mas, como qualquer campo / nova linguagem, existem convenções que seguem de hardware para hardware e, como tal, devem permanecer semelhantes em cada linguagem de montagem. Eu posso olhar para um trecho de assembly e ser capaz de obter a essência do código sem nunca usar esse conjunto de instruções, porque eles atendem a uma convenção, LDA ou alguma relação a ele provavelmente está carregando um registrador. MV provavelmente está movendo algo de algum lugar para outro. em outro lugar, não é sobre o que você acha legal ou é uma prática de alto nível, é uma linguagem em si mesma e, como tal, tem seus próprios padrões e significa que você, como designer, deve seguir, eles geralmente não são tão arbitrários quanto eles parecem.

Vou deixar você com isso: pedir à comunidade incorporada para usar práticas detalhadas de alto nível é como pedir aos químicos que sempre escrevam compostos químicos. O químico as escreve para si e qualquer outra pessoa no campo entenderá, mas pode demorar um pouco para um recém-chegado se adaptar.

Uma razão pela qual eles usam identificadores curtos enigmáticos é porque não são enigmáticos para os desenvolvedores. Você deve perceber que eles trabalham com isso todos os dias e esses nomes são realmente nomes de domínio. Então eles sabem de cor o que exatamente TIFR1 significa.

Se um novo desenvolvedor vier para a equipe, ele precisará ler as planilhas de dados (conforme explicado por @KarlBielefeldt) para que eles se sintam confortáveis ​​com elas.

Acredito que sua pergunta tenha sido um mau exemplo, porque, de fato, nesses tipos de códigos-fonte, você geralmente vê muitos identificadores de criptografia desnecessários para coisas que não são de domínio.

Eu diria que eles fazem isso principalmente devido aos maus hábitos que existiam quando os compiladores não concluíram automaticamente tudo o que você digitou.

Sumário

O inicialismo é um fenômeno generalizado em muitos círculos técnicos e não técnicos. Como tal, não se limita à programação de baixo nível. Para uma discussão geral, consulte o artigo da Wikipedia sobre acrônimo . Minha resposta é específica para programação de baixo nível.

Causas de nomes enigmáticos:

1. Instruções de baixo nível são fortemente tipadas
2. Precisa incluir muitas informações de tipo no nome de uma instrução de baixo nível
3. Historicamente, os códigos de um caractere são favorecidos para compactar as informações de tipo.

Soluções e suas desvantagens:

1. Existem esquemas modernos de nomeação de baixo nível que são mais consistentes que os históricos.
   • LLVM
2. No entanto, a necessidade de compactar muitas informações de tipo ainda existe.
   • Assim, ainda podem ser encontradas abreviações enigmáticas em todos os lugares.
3. A legibilidade linha a linha aprimorada ajudará um programador iniciante de baixo nível a entender o idioma mais rapidamente, mas não ajudará a compreender grandes partes do código de baixo nível.

Resposta completa

(A) Nomes mais longos são possíveis. Por exemplo, os nomes dos intrínsecos C ++ SSE2 têm em média 12 caracteres em comparação com os 7 caracteres no mnemônico de montagem. http://msdn.microsoft.com/en-us/library/c8c5hx3b(v=vs.80).aspx

(B) A pergunta passa para: quanto tempo / não criptográfico é necessário obter de instruções de baixo nível?

(C) Agora analisamos a composição de tais esquemas de nomeação. A seguir, são apresentados dois esquemas de nomeação para a mesma instrução de baixo nível:

• Esquema de nomeação # 1: CVTSI2SD
• Esquema de nomeação # 2: __m128d _mm_cvtsi32_sd (__m128d a, int b);

(C.1) As instruções de baixo nível são sempre fortemente digitadas. Não pode haver ambiguidade, inferência de tipo, conversão automática de tipo ou sobrecarga (reutilização do nome da instrução para significar operações semelhantes, mas não equivalentes).

(C.2) Cada instrução de baixo nível deve codificar muitas informações de tipo em seu nome. Exemplos de informações:

• Família de arquitetura
• Operação
• Argumentos (entradas) e saídas
• Tipos (número inteiro assinado, número inteiro não assinado, número flutuante)
• Precisão (largura do bit)

(C.3) Se cada informação for digitada, o programa será mais detalhado.

(C.4) Os esquemas de codificação de tipo usados ​​por vários fornecedores tinham raízes históricas longas. Como exemplo, no conjunto de instruções x86:

• B significa byte (8 bits)
• W significa palavra (16 bits)
• D significa dword "palavra dupla" (32 bits)
• Q significa qword "quad-word" (64 bits)
• DQ significa dqword "palavra quad-dupla" (128 bits)

Essas referências históricas não tinham nenhum significado moderno, mas ainda permanecem por aí. Um esquema mais consistente teria colocado o valor da largura de bit (8, 16, 32, 64, 128) no nome.

Pelo contrário, o LLVM é um passo certo na direção da consistência nas instruções de baixo nível: http://llvm.org/docs/LangRef.html#functions

(D) Independentemente do esquema de nomenclatura das instruções, os programas de baixo nível já são detalhados e difíceis de entender porque se concentram nos mínimos detalhes da execução. Alterar o esquema de nomenclatura das instruções melhorará a legibilidade em nível de linha a linha, mas não removerá a dificuldade de compreender as operações de um grande pedaço de código.

Os seres humanos lêem e escrevem assembléias apenas ocasionalmente, e na maioria das vezes é apenas um protocolo de comunicação. Ou seja, é mais frequentemente usado como uma representação serializada intermediária baseada em texto entre o compilador e o assembler. Quanto mais detalhada for essa representação, maior será a sobrecarga desnecessária neste protocolo.

No caso de códigos de operação e nomes de registros, nomes longos realmente prejudicam a legibilidade. Mnemônicos curtos são melhores para um protocolo de comunicação (entre compilador e dezembro), e a linguagem assembly é um protocolo de comunicação na maioria das vezes. Mnemônicos curtos são melhores para programadores, pois o código do compilador é mais fácil de ler.

Principalmente é idiomático. Como o @TMN diz em outro lugar, assim como você não escreve import JavaScriptObjectNotationou import HypertextTransferProtocolLibraryem Python, você não escreve Timer1LowerHalf = 0xFFFFem C. Parece igualmente ridículo no contexto. Todo mundo que precisa saber já sabe.

A resistência à mudança pode surgir, em parte, do fato de alguns fornecedores de compiladores C para sistemas embarcados divergirem do padrão e da sintaxe da linguagem, a fim de implementar recursos mais úteis à programação incorporada. Isso significa que você nem sempre pode usar o recurso de preenchimento automático do seu IDE ou editor de texto favorito ao escrever código de baixo nível, porque essas personalizações perdem a capacidade de analisar o código. Daí a utilidade de nomes curtos de registro, macros e constantes.

Por exemplo, o compilador C da HiTech incluía uma sintaxe especial para variáveis ​​que precisavam ter uma posição especificada pelo usuário na memória. Você pode declarar:

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

Agora, o único IDE existente que analisará isso é o próprio IDE da HiTech ( HiTide ). Em qualquer outro editor, você precisará digitá-lo manualmente, a partir da memória, sempre. Isso envelhece muito rapidamente.

Há também o fato de que, quando você estiver usando ferramentas de desenvolvimento para inspecionar registros, muitas vezes você terá uma tabela exibida com várias colunas (nome do registro, valor em hexadecimal, valor em binário, valor em binário, último valor em hexadecimal, etc.). Nomes longos significam que você precisa expandir a coluna de nome para 13 caracteres para ver a diferença entre dois registros e reproduzir "detectar a diferença" em dezenas de linhas de palavras repetidas.

Isso pode parecer bobagens bobas, mas nem todas as convenções de codificação são projetadas para reduzir o cansaço visual, diminuir a digitação supérflua ou resolver qualquer um de um milhão de outras pequenas reclamações?

Estou surpreso que ninguém tenha mencionado a preguiça e que outras ciências não sejam discutidas. Meu trabalho diário como programador mostra para mim que as convenções de nomenclatura para qualquer tipo de variável em um programa são influenciadas por três aspectos diferentes:

1. A formação científica do programador.
2. As habilidades de programação do programador.
3. O ambiente do programador.

Eu acho que não adianta discutir sobre programação de baixo ou alto nível. No final, sempre pode ser resumido aos três aspectos anteriores.

Uma explicação do primeiro aspecto: Muitos "programadores" não são programadores em primeiro lugar. Eles são matemáticos, físicos, biólogos ou mesmo psicólogos ou economistas, mas muitos deles não são cientistas da computação. A maioria deles tem suas próprias palavras-chave e abreviações específicas do domínio, que você pode ver nas suas "convenções" de nomes. Eles geralmente ficam presos em seu domínio e usam as abreviações conhecidas sem pensar em legibilidade ou guias de codificação.

Uma explicação do segundo aspecto: como a maioria dos programadores não é cientista da computação, suas habilidades de programação são limitadas. É por isso que eles geralmente não se importam com convenções de codificação, mas mais em convenções específicas de domínio, como declarado como primeiro aspecto. Além disso, se você não possui as habilidades de um programador, não possui o entendimento das convenções de codificação. Eu acho que a maioria deles não vê a necessidade urgente de escrever código compreensível. É como fogo e esqueça.

Uma explicação para o terceiro aspecto: é improvável que você freie com as convenções do seu ambiente, que podem ser códigos antigos que você precisa apoiar, padrões de codificação da sua empresa (administrados por economistas que não se importam com a codificação) ou o domínio ao qual você pertence. Se alguém começou a usar nomes enigmáticos e você precisa dar suporte a seu código, é improvável que altere os nomes enigmáticos. Se não houver padrões de codificação na sua empresa, aposto que quase todos os programadores escreverão seus próprios padrões. E, por último, se você estiver cercado por usuários do domínio, não começará a escrever outro idioma que eles usam.