Por que os identificadores curtos de criptografia ainda são tão comuns na programação de baixo nível?

64

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?

Roman Starkov
fonte
82
Resposta: Para parecer que você está programando em um idioma de baixo nível.
Thomas Eding
5
Críptico é relativo. JSRé três vezes maior que o código de operação que representa ( $20em um 6502) e consideravelmente mais fácil de entender rapidamente.
Blrfl
4
Estou um pouco decepcionado, porque a resposta correta está lá, mas definitivamente não é a aceita. Com diagramas de circuitos e essas interrupções, geralmente são nomeadas as linhas às quais estão associadas, e em um diagrama de circuitos que você não deseja, não é uma boa prática ou prática. Em segundo lugar, porque você não gosta das respostas não significa que elas não estão corretas.
Jeff Langemeier
4
@gnat: Tente set Accumulator32 to BaseIndex32? Simplesmente expandir as abreviações tradicionais não é a única maneira de tornar algo mais legível.
Timwi
11
"se o seu argumento principal é sobre o espaço físico em um diagrama de papel", não é sobre o fato de que a boa nomeação leva em consideração outras coisas além da clareza do nome (eu dei alguns em minha resposta, diagramas - incluindo os desenhados em um quadro-negro - são apenas uma dessas outras coisas) e esse esclarecimento é relativo (a familiaridade tende a ajudar a esclarecer qualquer que seja a escolha, por exemplo).
APROGRAMADOR

Respostas:

106

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:

Tabela TIFR1 da folha de dados

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

Karl Bielefeldt
fonte
7
Além disso, esta resposta realmente não abordar o lado de software puro, por exemplo CLR, JVM, x86, etc. :)
Timwi
12
@romkyns: É um pouco mais óbvio por que eles usaram esses nomes abreviados quando você realmente leu essas folhas de dados. As folhas de dados de um microcontrolador que tenho em mãos tem cerca de 500 páginas, mesmo quando se usa nomes abreviados . A largura das tabelas abrangeria várias páginas / telas se usássemos nomes mais longos, tornando-os muito inconvenientes para o uso de uma referência.
In silico
27
@romkyns: nomes mais longos são igualmente pesquisáveis, mas são "não nativos". Se você ouvir engenheiros incorporados, eles realmente dizem "zero tiffer", não "sinalizador de interrupção do timer zero". Duvido que os desenvolvedores da Web expandam HTTP, HTML ou JSON em seus nomes de métodos também.
TMN
6
@KarlBielefeldt er, what? :) Obviamente , não o encontrarei na folha de dados atual, porque eles escolheram o nome abreviado. Que não suporta a alegação de que nomes curtos são mais procurado na mínima ...
Roman Starkov
5
Não são apenas as planilhas de dados com restrição de espaço, são os esquemas. Todos esses componentes lógicos têm leads que precisam ser conectados a outros componentes. "TimerCounter1InteruptFlag.clear" não se encaixa no topo de uma representação de arame minúsculo tão bem "TCIF.C"
AShelly
60

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.

Caleb
fonte
2
obrigado Caleb! Para mim, este excelente resposta salvado uma questão que de alguma forma conseguiu arrecadar quatro juízos de valor em um título: "enigmática", "short", "ainda", "tão comum"
mosquito
11
Obrigado, @gnat, pelo seu comentário e pelo seu generoso bônus.
Caleb
37

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.

AProgrammer
fonte
4
É TIFR1realmente um esquema de nomeação melhor do que no InterruptFlag1entanto, ou IptFlag1se você realmente precisa ser curto?
Timwi
4
@ Timwi, InterruptFlage IptFlagsão melhores que IFda mesma maneira que EnumerableInterfacee ItfcEnumerablesão melhores que IEnumerable.
AProgrammer 29/08/2012
@ AProgrammer: Considero a sua resposta e o seu comentário o melhor, e eu o marcaria como aceito, se pudesse. Aqueles que acreditam que apenas os limites físicos ditam nomes curtos estão errados. Esta discussão será interessante para você: 37signals.com/svn/posts/…
alpav
5
@alpav Você percebe que o seu link argumenta o oposto do que esta resposta diz? Se houver, ele é totalmente compatível InterruptFlag1por razões de melhor clareza.
Roman Starkov
24

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.

mattnz
fonte
Se eu entendi o argumento que você usa para defender "bge.s", TIFR1é mais legível para quem precisa conhecê-lo TimerCounter1InterruptFlag, correto?
Roman Starkov
2
@romkyns: Absolutamente - neste caso, menos é mais .... Ao contrário do CNTR, que pode significar "Contador", "Controle", "Não é possível rastrear a rota" etc., T1FR1 Significado definido com precisão.
mattnz
"Se você não consegue entender o que é bge.s e acha que branch-se-maior-ou-igual.short fará a diferença - você está apenas brincando com o CLR e não sabe disso." Eu não sei disso. Entendo muito bem a montagem x86, mas toda vez que escrevo um loop, tenho que procurar o que todas as 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.
Cody Grey #
11

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.

Roman Starkov
fonte
10

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.

Jeff Langemeier
fonte
11
Eu sinto que "usaremos nomes enigmáticos porque é isso que faz a programação de baixo nível parecer" e "usaremos nomes enigmáticos porque essa é a convenção para programação de baixo nível" são praticamente os mesmos, então +1 de mim e pensarei em aceitar isso como uma variante menos inflamatória daquela que aceitei inicialmente .
Roman Starkov 14/01
6
+1 para a referência de químicos, pois gera uma boa analogia para os diferentes domínios da programação.
4
Eu também nunca entendi por que as pessoas usam nomes curtos e enigmáticos como "água" se existe o "DiHydrogenOxyde" muito mais legível.
Ingo
6

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.

Alex
fonte
5

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.

rwong
fonte
11
A legibilidade linha a linha aprimorada necessariamente terá algum impacto na compreensão da coisa toda, mas nomear sozinho não pode torná-la trivial, é claro.
Roman Starkov 14/01
3
Além disso, tipo de off-topic, mas CVTSI2SDnão carrega nenhuma outra informação além ConvertDword2Doubleou ConvInt32ToFloat64, mas o último, mais algum tempo, são instantaneamente reconhecíveis, enquanto que o primeiro deve ser decifrado ...
Roman Starkov
2

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.

SK-logic
fonte
Se você precisar economizar espaço, basta compactá-lo! ... Se você não precisar de sobrecarga, use um formato binário! Se você estiver usando texto, seu objetivo é facilitar a leitura - por que não percorrer todo o caminho e torná-lo adequadamente legível?
Roman Starkov 13/01
2
@romkyns, compactando um protocolo de comunicação baseado em texto entre dois processos locais? Isso é algo novo. Protocolos binários são muito menos robustos. É uma maneira unix - os protocolos baseados em texto existem para facilitar a leitura ocasional . Eles são legíveis apenas o suficiente.
SK-logic
Direito. Sua premissa é que eu leio e escrevo os nomes desses registros ou instruções CIL, pouco o suficiente para que as despesas gerais sejam importantes. Mas pense sobre isso; eles são usados ​​sempre que qualquer método ímpar ou nome de variável em qualquer outra linguagem de programação enquanto você estiver programando . Isso é tão raro que os poucos bytes extras importam?
Roman Starkov 13/01
11
Eu respeito o seu direito de ter um gosto diferente de quanto tempo os nomes devem ter, mas você realmente nomeia métodos e locais nos seus compiladores, coisas enigmáticas como TIFR, ou eles tendem a conter palavras completas?
Roman Starkov 13/01
11
Não vejo diferença relevante para o trade-off legível x curto. Eu os vejo como diferentes, é claro, assim como variáveis ​​são diferentes para funções que são diferentes para tipos. Eu simplesmente não vejo por que os códigos de código e os nomes de registros se beneficiam de ser extremamente curto a ponto de precisar consultar a documentação de todos os recém-encontrados antes que você tenha alguma idéia do que faz. Até agora, seu único argumento é armazenamento eficiente, se não me engano. Você realmente quis dizer isso? ... Ou você tem outros motivos?
Roman Starkov 14/01
1

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?

detly
fonte
2
Todos os seus argumentos fazem sentido. Eu entendo completamente todos esses pontos. No entanto, você não acha que exatamente o mesmo se aplica ao código de alto nível? Você também precisa ver uma tabela de locais em uma função C #. O contexto é subjetivo e File.ReadAllBytestambém pode parecer ridiculamente longo para alguém acostumado fread. Então ... por que tratar o código de alto e baixo nível de maneira diferente ?
Roman Starkov 14/01
@romkyns - Entendo o seu ponto, mas acho que não tratamos o código de alto nível de maneira muito diferente. As abreviações são boas em muitos contextos de alto nível, apenas não percebemos porque estamos mais acostumados com a abreviação ou com qualquer esquema que a acompanhe. Quando realmente escrevo funções ou crio variáveis ​​em código de baixo nível, uso bons nomes descritivos. Mas quando me refiro a um registro, fico feliz por poder olhar para um amontoado de letras e números e pensar rapidamente em "T = cronômetro, SE = sinalizador de interrupção, 1 = primeiro registro". É quase como química orgânica a esse respeito: P
detly
@romkyns - Além disso, em um sentido puramente prático, eu acho que a diferença entre uma tabela de registros no IDE e desenvolvimento de aplicações de algum microprocessador em C # é esta: uma tabela de regista até pode parecer: 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 com T1IF. Eu não acho que você criaria uma lista enorme de variáveis ​​em C # que mal diferem assim.
detly
11
@romkyns - O que você pode não estar ciente de é o fato de que não tenha havido uma mudança em relação ao que você descreve. Os compiladores recentes do Microchip vêm com bibliotecas muito mais detalhadas e descritivas do que apenas registros, por exemplo. 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.
detly
@detly: O compilador CCS tinha tais métodos, e alguns outros processadores fazem isso. Eu geralmente não gosto deles. A especificação do registro é suficiente para escrever código que usa os registros e é suficiente para permitir que alguém leia o código que usa registros para ver o que esses registros fazem. Se o ato de escrever um valor de N em um hardware pré-escalar definir o período como N + 1 (bastante comum), o significado adequado de set_prescalar(TMR4,13);é IMHO muito menos claro do que seria TMR4->PSREG=12;. Mesmo se olharmos para o manual do compilador para descobrir o que o primeiro código faz, um, provavelmente, ainda tem que ...
supercat
1

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.

Wagnerpeer
fonte
ninguém mencionou preguiça - talvez seja porque isso não seja relevante aqui. E que outras ciências não são discutidas, oh, é fácil: este site não é para discussão . É para perguntas e respostas
gnat
Preguiça é uma razão legítima. Quase todos os programadores são pessoas preguiçosas (caso contrário, faríamos tudo manualmente ooo!).
21416 Thomas Eding