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 deTimerCounter1InterruptFlag
),ICR1H
(em vez deInputCapture1High
),DDRB
(em vez deDataDirectionPortB
), etc. - Conjunto de instruções .NET CLR (2002):
bge.s
(em vez debranch-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?
fonte
JSR
é três vezes maior que o código de operação que representa ($20
em um 6502) e consideravelmente mais fácil de entender rapidamente.set Accumulator32 to BaseIndex32
? Simplesmente expandir as abreviações tradicionais não é a única maneira de tornar algo mais legível.Respostas:
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.
fonte
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
, eand
são muito curtos, enquanto palavras que são usadas menos frequentemente gostoobserve
,comprehension
everbosity
sã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
,or
enot
para 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.fonte
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:
Observe que essas recomendações são conflitantes.
Mnemônicos de instruções
Como programador de linguagem assembly, usar
short-branch-if-greater-or-equal
forbge.s
me dá a mesma impressão que quando vejo, como um programador Algol fazendo geometria computacional, emSUBSTRACT THE-HORIZONTAL-COORDINATE-OF-THE-FIRST-POINT TO THE-HORIZONTAL-COORDINATE-OF-THE-SECOND-POINT GIVING THE-DIFFERENCES-OF-THE-COORDINATE-OF-THE-TWO-POINTS
vez dedx := 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
TIFR1
essas, para que haja menos chance de confusão. Um ponto aqui é queTIFR1
não é uma abreviação aleatória, é o resultado de um esquema de nomeação.fonte
TIFR1
realmente um esquema de nomeação melhor do que noInterruptFlag1
entanto, ouIptFlag1
se você realmente precisa ser curto?InterruptFlag
eIptFlag
são melhores queIF
da mesma maneira queEnumerableInterface
eItfcEnumerable
são melhores queIEnumerable
.InterruptFlag1
por razões de melhor clareza.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 convencerbge.s
e achabranch-if-greater-or-equal.short
que 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.
fonte
TIFR1
é mais legível para quem precisa conhecê-loTimerCounter1InterruptFlag
, correto?j?
instruções significam. Ter uma instrução com nome mais óbvio definitivamente me ajudaria. Mas talvez eu seja a exceção e não a regra. Tenho dificuldade em lembrar detalhes triviais.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?
branch-if-greater-than-or-equal.short
é inicialmente mais legível do quebge.s
, mas com alguma prática a situação se inverte.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.
fonte
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.
fonte
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.
fonte
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:
Soluções e suas desvantagens:
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:
CVTSI2SD
__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:
(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:
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.
fonte
CVTSI2SD
não carrega nenhuma outra informação alémConvertDword2Double
ouConvInt32ToFloat64
, mas o último, mais algum tempo, são instantaneamente reconhecíveis, enquanto que o primeiro deve ser decifrado ...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.
fonte
TIFR
, ou eles tendem a conter palavras completas?Principalmente é idiomático. Como o @TMN diz em outro lugar, assim como você não escreve
import JavaScriptObjectNotation
ouimport HypertextTransferProtocolLibrary
em Python, você não escreveTimer1LowerHalf = 0xFFFF
em 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:
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?
fonte
File.ReadAllBytes
também pode parecer ridiculamente longo para alguém acostumadofread
. Então ... por que tratar o código de alto e baixo nível de maneira diferente ?Timer1InterruptFlag
,Timer2InterruptFlag
, ...,Timer9InterruptFlag
,IOPortAToggleMask
,IOPortBToggleMask
, etc x100. Em uma linguagem de nível superior, você usaria variáveis que diferem muito mais ... ou usaria mais estrutura.Timer1InterruptFlag
é 75% de ruído irrelevante em comparação comT1IF
. Eu não acho que você criaria uma lista enorme de variáveis em C # que mal diferem assim.UARTEnable(UART1, BITS_8, PARITY_N, STOP_1, BAUD_115200)
. Mas eles ainda são incrivelmente desajeitados e envolvem muita indireção e ineficiência. Eu tento usá-los sempre que possível, mas na maioria das vezes, envolvo a manipulação do registro em minhas próprias funções e a chamo da lógica de nível superior.set_prescalar(TMR4,13);
é IMHO muito menos claro do que seriaTMR4->PSREG=12;
. Mesmo se olharmos para o manual do compilador para descobrir o que o primeiro código faz, um, provavelmente, ainda tem que ...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:
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.
fonte