Existe uma desculpa para nomes curtos de variáveis?


140

Isso se tornou uma grande frustração com a base de código em que estou trabalhando; muitos de nossos nomes de variáveis ​​são curtos e não descritivos. Sou o único desenvolvedor que resta no projeto e não há documentação sobre o que a maioria deles faz; portanto, preciso dedicar mais tempo a rastrear o que eles representam.

Por exemplo, eu estava lendo algum código que atualiza a definição de uma superfície óptica. As variáveis ​​definidas no início foram as seguintes:

double dR, dCV, dK, dDin, dDout, dRin, dRout
dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1));
dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1));
... and so on

Talvez seja só eu, mas não me disse essencialmente nada sobre o que eles representavam, o que dificultou a compreensão do código. Tudo que eu sabia era que era uma variável analisada em uma linha específica de uma tabela específica, em algum lugar. Após algumas pesquisas, descobri o que elas significavam:

dR = radius
dCV = curvature
dK = conic constant
dDin = inner aperture
dDout = outer aperture
dRin = inner radius
dRout = outer radius

Renomeei-os para essencialmente o que tenho lá em cima. Isso alonga algumas linhas, mas eu sinto que isso é uma troca justa. Esse tipo de esquema de nomenclatura é usado em grande parte do código. Não tenho certeza se é um artefato dos desenvolvedores que aprenderam trabalhando com sistemas mais antigos ou se há uma razão mais profunda por trás disso. Existe uma boa razão para nomear variáveis ​​dessa maneira, ou estou justificado em atualizá-las para nomes mais descritivos à medida que os encontro?


98
Parece-me que, nesse caso específico, esses são nomes de variáveis ​​copiados diretamente de uma fórmula matemática longhand.
Dave Nay


35
Se você não conseguir entender o código matemático por causa dos nomes curtos das variáveis, saiba que pode ser porque você não entende a matemática, não porque os nomes são muito curtos. Alterar expressões matemáticas que você não entende não é um processo de alta confiabilidade. Depois de entender a matemática, o tamanho dos nomes das variáveis ​​é irrelevante. Faça um favor aos outros e deixe uma citação (em um comentário) para alguma descrição relevante da matemática, se você tiver que aprender!
Rex Kerr

3
Qualquer identificador que é nomeado após Donkey Kong é aprovado: dK = conic constant.
Thomas Eding

8
Por outro lado, alguém poderia perguntar se a ignorância do campo do domínio justifica ignorar suas convenções. No final, isso depende do contexto.
Daniel C. Sobral

Respostas:


234

Parece que esses nomes de variáveis ​​são baseados nas abreviações que você esperaria encontrar em um livro de física que trabalha com vários problemas de óptica. Essa é uma das situações em que nomes curtos de variáveis ​​geralmente são preferíveis a nomes mais longos. Se você tem físicos (ou pessoas que estão acostumadas a trabalhar as equações manualmente) que estão acostumadas a usar abreviações comuns como Rin, Rout, etc., o código será muito mais claro com essas abreviações do que com nomes de variáveis ​​mais longos. Também facilita a comparação de fórmulas de papéis e livros didáticos com o código, para garantir que o código esteja realmente fazendo os cálculos corretamente.

Qualquer pessoa familiarizada com a óptica reconhecerá imediatamente algo como Rin como o raio interno (em um artigo de física, inisso seria renderizado como um índice), Rout como o raio externo, etc. Embora eles quase certamente possam traduzir algo mentalmente como innerRadiusna nomenclatura mais familiar, isso tornaria o código menos claro para essa pessoa. Tornaria mais difícil identificar casos em que uma fórmula familiar tivesse sido codificada incorretamente e tornaria mais difícil a tradução de equações no código de e para as equações que eles encontrariam em um artigo ou livro.

Se você é a única pessoa que analisa esse código, nunca precisa traduzir entre o código e uma equação óptica padrão, e é improvável que um físico precise analisar o código no futuro, talvez isso aconteça. faz sentido refatorar porque o benefício das abreviações não supera mais o custo. Se esse fosse um novo desenvolvimento, no entanto, quase certamente faria sentido usar as mesmas abreviações no código que você encontraria na literatura.


17
E se não houver físicos ou matemáticos na equipe? O código foi essencialmente deixado para mim. É em grande parte indocumentado. Seria mais difícil ler os nomes descritivos?
KChaloux

127
+1 Não é irracional esperar que um programador entenda o domínio em que está trabalhando. Por outro lado, em trabalhos matemáticos, as variáveis ​​geralmente são definidas em um local conveniente. Em um código como esse, eu esperaria um comentário importante mostrando o formato longo.
Karl Bielefeldt

15
+1: O que você está dizendo basicamente é que um programador que entende o domínio em que está trabalhando entenderá os nomes das variáveis. Isso será o mesmo em muitos projetos, mesmo com nomes de variáveis ​​mais longos. por exemplo. uma variável nomeada columnem um jogo de estratégia militar provavelmente significa algo diferente do que significaria nos gráficos de software.
Steven Evers

23
Na programação médica, você geralmente encontrará termos que persistem na esfera da programação. Por exemplo, com oftalmologia, você verá OU, OD e OS. Eles indicam qual olho, por exemplo, o ouSphere pode fazer referência ao componente "esfera" de uma prescrição de óculos para o olho direito. Você será um programador melhor se entender o domínio comercial para o qual está programando.
Bill

11
+1 por observar os nomes abreviados que correspondem aos das equações e fórmulas de papéis e textos. Quando faço isso, incluo os comentários sobre onde encontrar o material de referência original.
Jay Elston

89

Variáveis ​​com vida útil curta devem ser nomeadas em breve. Como exemplo, você não escreve for(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { .... Em vez disso, você usa for(int i ....

Em regra geral, pode-se dizer que quanto menor o escopo da variável, menor o nome. Os contadores de loop geralmente são apenas letras únicas, digamos i, je k. Variáveis ​​locais são algo como baseou frome to. Variáveis ​​globais são então um pouco mais elaboradas, por exemplo EntityTablePointer.

Talvez uma regra como essa não esteja sendo seguida com a base de código com a qual você trabalha. É uma boa razão para refatorar!


14
i, j e k para índices de matriz representam uma tradição que remonta pelo menos a Fortran. Qualquer programador que se preze estará familiarizado com esta convenção.
Dominic Cronin

7
I geralmente não escrever i, j, k, eu escrevo algo como personPosporque então eu não vou esquecer o que estou a iteração de eo que o índice representa.
Malcolm

18
-1, eu uso nomes longos para iterações de índice de matriz, mas dou a eles um nome significativo em vez de óbvio e sem sentido arrayCounter . Facilita a leitura do código e, pelo menos, evita que você pisoteie todo o contador externo ao copiar / colar outro loop dentro deste.
amigos estão dizendo sobre oleg V.

3
counter é um substantivo ou um adjetivo. Count é um substantivo ou um verbo. Claro, eu ainda não chamaria algo arrayCounter, usaria personIndexou rowdescrevia o que estou vendo.
Wayne Werner

6
Quando estou fazendo um único loop, eu uso i. Mas assim que faço a transição para um loop aninhado, largo a inomenclatura. A razão para isso é porque eu realmente quero acompanhar com qual variável de loop está sendo trabalhada, e ivs jpode enganar bastante o código denso. Tornar mais legível e adicionar mais espaço em branco é inerentemente necessário para mim.
precisa saber é o seguinte

48

O problema com o código não são os nomes abreviados, mas a falta de um comentário que explique as abreviações ou aponte para alguns materiais úteis sobre as fórmulas das quais as variáveis ​​são derivadas.

O código simplesmente assume a familiaridade do domínio do problema.

Tudo bem, uma vez que provavelmente é necessário familiarizar o domínio do problema para entender e manter o código, especialmente no papel de alguém que o "possui", de modo que é necessário adquirir a familiaridade em vez de procurar nomes mais longos.

Mas seria bom se o código fornecesse algumas dicas para servir como trampolins. Mesmo um especialista em domínio pode esquecer que dKé uma constante cônica. Adicionar um pequeno "truque" em um bloco de comentários não faria mal.


No fim, acabamos indo com algo assim.
KChaloux

5
Isto está errado. Não há razão para dificultar a leitura do seu código para forçar as pessoas a gastar mais tempo "aprendendo". Você não está ensinando, apenas está diminuindo a velocidade das pessoas. Além disso, praticamente nunca existe um único proprietário de código para sempre. Você está sendo míope e egoísta.
Xaxxon

7
É sua interpretação que está errada, não a resposta. O código implementa algumas matemáticas que existem fora desse código e independentemente dele, e que vieram antes do código. Manter o mesmo nome é útil. Alguém que mantém o código provavelmente terá que estudar isso fora da matemática, e não ter que mapear entre dois esquemas de nomeação ajudará essa pessoa.
Kaz

19

Para determinadas variáveis ​​que são bem conhecidas no domínio do problema - como o caso que você tem aqui - nomes de variáveis ​​concisos são razoáveis. Se estou trabalhando em um jogo, quero que minhas entidades de jogo tenham variáveis ​​de posição xe y, não horizontalPositione verticalPosition. Da mesma forma contadores de loop que não têm qualquer semântica para além de indexação, espero ver i, j, k.


Eu diria que cv, din e dout não são imediatamente óbvios (embora aparentemente eles estejam estabelecidos em campos específicos). Eu não argumentaria sobre xey, visto que as coordenadas cartesianas são aplicáveis ​​a qualquer número de campos e são ensinadas a todos no ensino médio e médio.
KChaloux

1
E xe y, embora comuns, não carregam aspectos implícitos importantes, como onde a origem.
Ross Patterson

3
@ RossPatterson: no entanto, existem muitos contextos em que isso simplesmente não é importante. Por exemplo, considere um loop como for (x,y) in list_of_coordinates: print x,y: A origem não importa particularmente ao tentar entender o código.
Bryan Oakley

16

De acordo com o "Código Limpo":

Os nomes das variáveis ​​devem:

  • Seja revelador de intenção
  • Evite desinformação
  • Faça distinções significativas
  • Seja pronunciável
  • Seja pesquisável

Exceções são as proverbiais i,j,k,m,nusadas para loops.

Os nomes das variáveis ​​das quais você, por direito, reclama, não fazem nada do exposto acima. Esses nomes são nomes ruins.

Além disso, como todo método deve ser curto , o uso de prefixos para indicar escopo ou tipo não está mais em uso.

Estes nomes são melhores:

radius
curvature
conicConstant
innerAperture
outerAperture
innerRadius
outerRadius

Um comentarista diz que isso seria muito complexo com nomes de variáveis ​​longos:

insira a descrição da imagem aqui

Nomes curtos de variáveis ​​também não simplificam:

fnZR = (r^2/fnR(1+Math.sqrt((1+k) * (r^2/R^2)))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;

A resposta são nomes longos e resultados intermediários até você obter isso no final:

thisNiceThing =  ( thisOKThing / thisGreatThing ) + thisAwsomeThing;

26
Essas variáveis ​​provavelmente são usadas em fórmulas matemáticas no código. Fórmulas matemáticas são muito mais fáceis de ler com nomes curtos de variáveis. Uso nomes de variáveis ​​longos na maior parte do meu código, mas a matemática é melhor com nomes curtos de variáveis. Exemplo aleatório: considere quanto tempo isso levaria com nomes longos de variáveis.
MarkJ

@ MarkJ Você está certo.
Tulains Córdova

1
Resultados intermediários têm o benefício adicional de reduzir e isolar erros de programação. Nosso cérebro só pode processar tantas informações de cada vez, e é difícil identificar o erro em algo comofnZR = (r^2/fnR(1+Math.sqrt((1+k)) * (r^2/R^2))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;
ausência de pálpebra 02/02

1
Não é tão difícil se esse é o seu pão com manteiga.
Radu

1
O ponto não é escrever uma frase. Mas o problema é que, se você precisa mudar algo e utilizar outra fórmula agora você tem um problema onde ele leva muito tempo para descobrir qual long_nameo Rno livro se refere. Use resultados intermediários, mas mantenha sua matemática complexa o mais próxima possível do domínio do problema, para que você possa realmente mantê-la se precisar adicionar um recurso.
slebetman 17/09/14

8

Há duas boas razões para não renomear variáveis ​​no código herdado.

(1) a menos que você esteja usando uma ferramenta de refatoração automatizada, a possibilidade de introduzir bugs é alta. Portanto, "se não estiver quebrado, não conserte"

(2) você fará comparando versões atuais com versões anteriores, para ver o que mudou, impossível. Isso tornará a manutenção futura do código mais difícil.


7
Absolutamente correto, mas o risco de falta de entendimento é muito maior.
Ross Patterson

2
Você tem problemas muito maiores se suas ferramentas não puderem lidar com problemas simples como os que você mencionou.
AndSoYouCode

Respostas (1) Cobertura de teste automatizada razoável e encapsulamento sadio, (2) Proficiência no controle de versão.
Adamantish

5

Existe uma boa razão para nomear variáveis ​​dessa maneira, ou estou justificado em atualizá-las para nomes mais descritivos à medida que os encontro?

O motivo para usar nomes menores é se o programador original acha mais fácil trabalhar com eles. Presumivelmente, eles têm o direito de descobrir que esse é o caso e o direito de não ter as mesmas preferências pessoais que você possui. Pessoalmente, eu encontraria ...

dDin better than dDinnerAperture
dDout better than dDouterAperture

... se eu os estivesse usando em cálculos longos e complexos. Quanto menor a expressão matemática, geralmente é mais fácil ver a coisa toda de uma só vez. Embora esse fosse o caso, eles poderiam ser melhores como dIn e dOut, portanto não havia um D repetitivo que pudesse levar a um erro de digitação fácil.

Por outro lado, se você achar que é mais difícil trabalhar com isso, se nocauteie e renomeie para a forma mais longa. Especialmente se você for responsável por esse código.


7
Pelo menos eu estou certamente se livrar dos Sistemas de notação húngara ...
KChaloux

4
O líder dé húngaro? Eu pensei que era cálculo como em dx^2/dx = 2x.
Shannon Severance

7
Se eu visse dDinnerAperturepor si só, eu o leria como "Dinner Aperture" e me perguntaria se é apenas uma maneira engraçada de dizer "sua boca". Nunca fui fã do estilo "letra maiúscula seguida de letra minúscula). Às vezes, muito confuso."
Darrel Hoffman

2
+1 esta é a resposta. Fórmulas matemáticas longas são muito mais fáceis de ler com nomes de variáveis curtos. Essas variáveis ​​provavelmente são usadas em fórmulas matemáticas no código. Fórmulas matemáticas são muito mais fáceis de ler com nomes curtos de variáveis. Uso nomes de variáveis ​​longos na maior parte do meu código, mas a matemática é melhor com nomes curtos de variáveis. Exemplo aleatório: considere quanto tempo isso levaria com nomes longos de variáveis.
MarkJ

1
@ ShannonSeverance Concordo com você. Vindo de uma experiência em engenharia, d deve definitivamente ser reservado para cálculo ao usar nomes de variáveis ​​no sentido matemático (como é frequentemente mencionado aqui).
precisa saber é o seguinte

4

Geralmente, acredito que a regra para isso deve ser o uso de nomes de variáveis ​​extremamente curtos, onde você sabe que as pessoas "especializadas na arte" do seu código específico entenderão imediatamente a referência desse nome de variável. (Você sempre tem comentários para a exceção deste caso) e que o uso localizado das variáveis ​​pode ser facilmente discernido com base no contexto de como elas são usadas.

Para expandir isso, significa que você não deve se esforçar para ofuscar seus nomes de variáveis, mas pode usar abreviações para seus nomes de variáveis, onde sabe que apenas as pessoas que entendem o conceito subjacente do seu código provavelmente para ler de qualquer maneira.

Para usar um exemplo do mundo real, recentemente, eu estava criando uma classe Javascript com latitude e informando a quantidade de luz solar que você esperaria em uma determinada data.

Para criar esta classe Sundial , me referi talvez meia dúzia de recursos, a Astronomia Almanac, e trechos de outras línguas, (PHP, Java, C etc).

Em quase todas elas, usavam abreviações idênticas semelhantes, que, à primeira vista, não significam nada absoluto.

K, T, EPS, deltaPsi, eot, LM,RA

No entanto, se você tem conhecimento de física, pode entender o que eram. Eu não esperaria que mais alguém tomasse esse código. Por que usar nomes de variáveis ​​detalhados?

julianTime, nutationOfEclipticalLongitudeExpressedInDegrees, equationOfTime, longitudeMean, rightAscension.

Além disso, na maioria das vezes, quando os nomes de variáveis ​​são transitórios, ou seja, eles são usados ​​apenas para alocar temporariamente algum valor, frequentemente não faz sentido usar uma versão detalhada, especialmente quando o contexto da variável explica seu objetivo.


1

Absolutamente existe; Muitas vezes, basta um nome curto de variável.

No meu caso, estou navegando no waypoint na minha turma de robótica sênior e programamos nossos robôs no KISS-C. Precisamos de variáveis ​​para coordenadas de corrente e destino (x, y), distâncias (x, y), títulos de corrente e destino, bem como ângulos de viragem.

Especialmente no caso das coordenadas xey, um nome de variável longo é completamente desnecessário, e nomes como xC (x atual), yD (destino y) e pD (destino phi) são suficientes e são os mais fáceis de entender nesse caso.

Você pode argumentar que esses não são 'nomes de variáveis ​​descritivos' como o protocolo do programador ditaria, mas como os nomes são baseados em um código simples (d = destino, c = atual), um comentário muito simples no início é toda a descrição eles exigem.


0

Existe uma boa razão para nomear variáveis ​​dessa maneira, ou estou justificado em atualizá-las para nomes mais descritivos à medida que os encontro?

Geralmente, algoritmos complexos são implementados no matlab (ou linguagem similar). O que eu vi são pessoas apenas assumindo o nome das variáveis. Dessa forma, é simples comparar implementações.

Todas as outras respostas estão quase corretas. Essas abreviações podem ser encontradas em matemática e física, exceto que elas não começam d(como no seu exemplo). As variáveis ​​que começam com d geralmente são nomeadas para representar diferenciação .

Todos os guias de codificação normais estão dizendo para não nomear variáveis ​​com a primeira letra representando o tipo (como no seu caso), porque é muito fácil procurar o código em todos os IDEs modernos.


Certo, esse elemento estava desaparecendo, independentemente do que as pessoas acabassem dizendo. Há uma espécie de esquizofrenia meio húngara e meio não acontecendo na base de código que estou atualizando à medida que a encontro.
KChaloux

0

Eu posso pensar em uma razão para nomes de variáveis ​​serem razoavelmente curtos.

Os nomes abreviados são fáceis de ler usando um período de visão mais curto, daí um período curto de atenção.

Por exemplo, quando me acostumo ao fato de que svdb significa "salvar no banco de dados", a taxa de varredura do código-fonte aumenta, pois só preciso varrer rapidamente 4 caracteres em vez de ler SaveToDatabase (14 caracteres, as coisas pioram) para nomes de operações mais complexos). Eu digo "varredura" e não "leitura", porque isso leva uma grande parte da análise do código fonte.

Ao digitalizar uma grande quantidade de código-fonte, isso pode proporcionar bons ganhos de desempenho.

Além disso, apenas ajuda o programador preguiçoso a digitar esses nomes abreviados ao escrever código.

Obviamente, espera-se que todos esses "atalhos" sejam listados em algum local padrão no código-fonte.


1
Nós não lemos palavras como um conjunto de caracteres, lemos como formas e resolvemos detalhes condicionalmente quando a compreensão rápida falha. O tamanho que uma palavra deve demorar para ser lida é muito maior que 4 caracteres, e somos capazes de processar mentalmente o camelCase e outros meios de dividir palavras de nomes variáveis ​​como limites de palavras. Duvido que um teste de leitura confirme a afirmação de que nomes mais curtos melhoram a velocidade da compreensão da leitura; ao invés disso, removendo palavras reconhecíveis, haverá uma diminuição na velocidade até que as novas palavras sejam assimiladas (o que você mesmo indica).
Eyelidlessness

0

Para enquadrar o que o @zxcdw disse de uma maneira um pouco diferente e elaborar em termos de abordagem:

As funções devem ser puras , breves e um encapsulamento perfeito de algumas funcionalidades: lógica da caixa preta , independentemente de permanecer intocada por 40 anos, continuará a fazer o trabalho para o qual foi projetada, devido à sua interface (entrada e saída) é bom, mesmo que você não saiba nada sobre o seu interior.

Este é o tipo de código que você deseja escrever: este é o código que dura e é simples de portar.

Onde necessário, componha funções a partir de outras chamadas de função (em linha) , para manter o código refinado.

Agora, com um nome de função adequadamente descritivo (detalhado, se necessário!), Minimizamos qualquer chance de interpretação incorreta desses nomes de variáveis ​​abreviados, pois o escopo é muito pequeno.


-1

Os nomes de variáveis ​​devem ser o mais descritivos possível para ajudar a legibilidade do programa. Você mesmo experimentou: teve muitos problemas para identificar o que o programa fez devido à má nomeação.

Não há uma boa razão para não usar o nome descritivo. Isso ajudará você e todos os outros que trabalham / irão trabalhar no projeto. Bem, na verdade, existe um único uso válido para nomes abreviados: contadores de loop.


6
Observe que int dummy_variable_for_for_loops;é o mais descritivo possível.
Kaz

4
-1 porque esta resposta é confusa. Primeiro, ele diz que não há boas razões, depois termina dizendo que realmente existem. A resposta seria melhor se fosse reformulada para não se contradizer.
Bryan Oakley

Eu mudaria que para ler "tão descritivo quanto necessário ". Se um nome abreviado transmitir a finalidade da variável, não há problema em usar um nome abreviado .
Maximus Minimus

-1

Certamente é para isso que servem os comentários?

Se as atribuições tiverem comentários descritivos, você obtém o melhor dos dois mundos: uma descrição da variável e de quaisquer equações são facilmente comparáveis ​​às de seus colegas de livros didáticos.


-1

Para interfaces (por exemplo, assinaturas de método, assinaturas de função), costumo resolver isso anotando as declarações de parâmetro. Para C / C ++, isso decora o arquivo .h, bem como o código da implementação.

Eu faço o mesmo para declarações de variáveis ​​em que o conhecimento do uso da variável não é óbvio no contexto e na nomeação. (Isso se aplica a idiomas que não possuem digitação forte também.)

Há muitas coisas que não queremos entupir o nome da variável. É o ângulo em radianos ou graus, existe alguma tolerância na precisão ou alcance, etc. As informações podem fornecer afirmações valiosas sobre características que devem ser tratadas corretamente.

Eu não sou religioso sobre isso. Estou simplesmente interessado na clareza e em garantir que agora seja o que é da próxima vez que o eu esquecido visitar o código. E quem olha por cima do meu ombro tem o que precisa saber para ver onde algo está errado, o que é essencial (o último crítico para a manutenção adequada).


-1

Existe uma desculpa para nomes de variáveis ​​excessivamente curtos?

Primeiro: Nomear uma variável para energia e ao calcular fórmulas como E = MC2 NÃO é nomeação excessivamente curta. Usar símbolos como argumento para nomes abreviados não é válido

Esta pergunta foi bastante interessante para mim, e só consigo pensar em uma desculpa e isso é dinheiro.

Digamos, por exemplo, que você esteja conectando o javascript para um cliente que sabe que o arquivo deve ser baixado muitos vezes por segundo. Seria mais barato e melhoraria a experiência dos usuários se o arquivo (em número de bytes) fosse o menor possível.

(Apenas para manter o exemplo "realista", você não tinha permissão para usar uma ferramenta minificadora, por quê? Problemas de segurança, nenhuma ferramenta externa pode tocar na base de código.)


1
Seu exemplo ainda não é muito realista.
Radu

-1

Percebo que as outras respostas não mencionam o uso da notação húngara. Isso é ortogonal ao longo debate, mas relevante para os esquemas de nomeação em geral.

double dR, dCV, dK, dDin, dDout, dRin, dRout

O "d" no início de todas essas variáveis ​​deve indicar que elas são duplas; mas o idioma está aplicando isso de qualquer maneira. Apesar da discrepância desses nomes, eles são até 50% redundantes !

Se vamos usar uma convenção de nomenclatura para reduzir erros, é muito melhor codificar informações que não estão sendo verificadas pelo idioma. Por exemplo, nenhum idioma reclamará dK + dRno código acima, mesmo que não faça sentido adicionar um número sem dimensão a um comprimento.

Uma boa maneira de evitar esses erros é usar tipos mais fortes; no entanto, se vamos usar duplos, um esquema de nomeação mais apropriado pode ser:

// Dimensions:
// l  = length
// rl = reciprocal length
double lR, rlCV, K, lDin, lDout, lRin, lRout

O idioma ainda nos permitirá escrever K + lR, mas agora os nomes nos dão uma dica de que isso pode estar incorreto.

Essa é a diferença entre sistemas húngaro (geralmente ruim) e aplicativos húngaro (possivelmente bom)

http://en.wikipedia.org/wiki/Hungarian_notation


1
Na verdade, o C ++ pode reclamar K + lR se você declarar corretamente suas unidades. Com unidades SI, ele pode fazer verificações de dimensionalidade e conversão de unidades. A adição não 3_feet + 2_meterdeve ser problema, enquanto 2_meter+1_seconddeve ser um erro em tempo de compilação.
MSalters

@MSalters Isso é muito legal; uma abordagem de modelo / macro não me ocorreu. Ainda assim, em uma pergunta "independente de idioma" como essa, agruparia todas as verificações de unidade em tempo de compilação sob o guarda-chuva de "tipos mais fortes", independentemente de o idioma os chamar de "tipos" ou não;)
Warbo

Modelo, necessariamente. Você não pode fazer o cálculo do tipo necessário nas macros.
MSalters

-2

O único caso em que nomes de variáveis ​​ilegivelmente curtos são aceitáveis ​​na engenharia de software moderna é quando eles existem em um script e a taxa de transferência desse script (geralmente em uma rede) é importante. Mesmo assim, mantenha o script com nomes longos no controle de origem e reduza o script em produção.


9
Que tal ao executar operações matemáticas em que os termos são considerados de conhecimento comum no domínio? Exemplo: usando M em vez de "massa" em e = mc ^ 2
Andy Hunt

2
@andyBursh - eu teria cuidado lá. Os programadores geralmente não são especialistas (ou mesmo competentes) em seu domínio de problemas. Dito isto, esse tipo de coisa pode ser bom, especialmente se houver o link de comentário apropriado para a fórmula em questão; Eu tinha me esquecido desse cenário.
Telastyn

8
@Telastyn - Se você presume que o programador não é um especialista, isso geralmente leva a abreviações com um significado muito bem definido e a transformá-las em nomes mais longos que são pelo menos um tanto ambíguos (ou seja, alguém decide nomear uma variável local radiusquando armazena o raio interno sem entender que é muito mais ambíguo do que Rin). E então o desenvolvedor não especialista precisa traduzir entre sua nomenclatura única e a nomenclatura que a empresa entende toda vez que há uma discussão envolvendo equações.
Justin Caverna

2
E o "i" para um contador de loop? Ou "x" e "y" ao lidar com uma coordenada? Ou uma variável cujo escopo é apenas duas linhas de código?
perfil completo de Bryan Oakley

4
Não concorde com esta resposta. Um programador que trabalha em um programa que contém expressões matemáticas complexas poderia pelo menos ler as fórmulas nas especificações, caso contrário, elas não são competentes. Isso não é conhecimento do domínio do problema, é uma habilidade essencial - alguma competência básica em matemática antes de trabalhar em um programa matemático. Se o programador não tiver acesso às fórmulas de especificações, isso é outro problema - e não pode ser resolvido apenas por comentários.
21412 MarkJ
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.