Os identificadores curtos são ruins? [fechadas]

Os identificadores curtos são ruins? Como o comprimento do identificador se correlaciona com a compreensão do código? Que outros fatores (além da compreensão do código) podem ser considerados quando se trata de nomear identificadores?

Apenas para tentar manter a qualidade das respostas, por favor, note que há algumas pesquisas sobre o assunto já!

Editar

Curioso que nem todos pensam que o comprimento é relevante ou tendem a preferir identificadores maiores, quando os dois links que forneci indicam que identificadores grandes são prejudiciais!

Link quebrado

O link abaixo apontava para uma pesquisa sobre o assunto, mas agora está quebrado, parece que não tenho uma cópia do artigo comigo e não me lembro o que era. Vou deixar aqui para o caso de alguém descobrir.

• http://evergreen.loyola.edu/chm/www/Papers/SCP2009.pdf

A melhor "regra" que ouvi é que o tamanho dos nomes deve ser proporcional ao tamanho do escopo da variável. Portanto, um índice ié bom se o corpo do loop tiver algumas linhas, mas eu gosto de usar algo um pouco mais descritivo, se for maior que 15 linhas.

Cada variável deve ter um significado e seu nome faz parte desse significado. E uma parte muito importante, pois ajuda o leitor a entender para que serve, sem se aprofundar no algoritmo. i, jsão óbvios para serem usados ​​como índices, são curtos, mas muito informativos. bnté feio closeou closeButtontem significado. Portanto, ser curto ou longo não é o critério mais importante para o nome da variável, mas deve ser significativo. A significância depende fortemente do contexto. Por exemplo, você pode dar um nome muito curto, como na variável de cadeia local, que é usada em um pequeno bloco do código, digamos 10 linhas e se refere ao nome de uma propriedade ( vpois valor é outro exemplo).

Portanto , os nomes de variáveis ​​devem ser informativos e não importa se são curtos ou longos .

Vou usar um identificador que descreva a variável, independentemente do comprimento.

Os casos de i, j e k são, por si só, tão onipresentes que são auto-descritivos, você automaticamente sabe que são índices de loop. Você também pode dizer o mesmo para:

foreach loop (Strings s : myString)

No entanto, os IDE agora fornecem ferramentas de preenchimento de código, portanto, o único efeito colateral negativo de identificadores muito longos e descritivos foi removido.

Felizmente, adicionarei uma palavra extra a um identificador, se necessário, para explicar o objetivo da variável.

Eles não são tão ruins quanto os identificadores enganosos. Não me importo com o código de depuração no qual os identificadores são apenas uma letra, mas no momento em que diferentes convenções de nomenclatura entram em cena, isso se torna irritante. Por exemplo, se em algum lugar você vê strPersonIDe depois em algum outro lugar s_EmployeeID, é confuso dizer se são essas duas strings e se há alguma diferença. Além disso, se as variáveis ​​forem copiadas e coladas ( pmapIntString = new std::map<int,int>) e estiverem totalmente erradas, vou me preocupar.

Quando se trata de mim, adiciono comentários no código para as variáveis ​​importantes usadas e tento manter o padrão fornecido nas diretrizes de desenvolvimento. Se não houver um padrão, tento manter a mesma convenção de nomenclatura em todo o código.

Eu luto...

Costumo usar sempre nomes descritivos como identificadores, mas ultimamente tenho usado identificadores muito curtos.

Eu acho que depende do contexto do código:

• Se você escrever funções complexas (algoritmos), SEMPRE use identificadores curtos (caracteres únicos são os melhores)
• Ao escrever valores de parâmetros para funções, use nomes descritivos.

Eu acho que depende também da densidade do código. Às vezes, ter nomes torna mais difícil a leitura.

Às vezes, sem nomes, é totalmente enigmático!

Meu pensamento é que eles não são ruins em si mesmos, mas são pouco informativos, a menos que sejam muito comuns.

Portanto, variáveis ​​de loop sendo i, j e k são tão padrão que não há razão para não usá-las se você estiver criando um loop indexado.

O outro lugar em que usarei um identificador muito curto é quando declaro uma variável temporária que ficará fora do escopo em poucas linhas - a variável temporária de um loop foreach, por exemplo. Se não for consultado em nenhum outro lugar, é fácil para quem lê o código ver a declaração e seguir para que está sendo usado. Porém, se for usado por mais de cinco ou seis linhas, procurarei dar um nome mais claro.

Além disso, tento usar identificadores informativos de comprimento - particularmente em nível de classe, quero um identificador que você possa ler e ter uma ideia do que é a variável. Se eles estão ficando muito longos (e às vezes vejo código com quatro ou cinco palavras juntas para um identificador), costumo considerar isso como um cheiro de código - se eu precisar de muito texto para distinguir minhas variáveis, na verdade eles são um grupo que poderia ser melhor armazenado em um hashmap ou lista? Eu poderia estar criando algum tipo de objeto para modelar esses dados com mais precisão? Às vezes, você não pode deixar de identificar um identificador muito longo, indicando que há algo que vale a pena examinar aqui.

Eu concordo muito com as outras respostas aqui, mas gostaria de apontar outro fator que acho que muitas vezes é esquecido. Um bom nome geralmente é idiomático para o código. Isso pode estar no nível da linguagem, no nível do algoritmo ou em alguns idiomas internos da base de código em questão. O ponto é que, embora o nome possa não significar nada para alguém que não conhece o domínio do código, ele ainda pode ser o melhor nome no contexto especificado.

Nomear uma variável é sempre um exercício para equilibrar exclusividade e compreensibilidade. O comprimento do nome está relacionado a ambos, de maneiras diferentes. Nomes mais longos são mais fáceis de tornar únicos; nomes de tamanho médio tendem a ser mais compreensíveis que nomes curtos ou longos demais.

Um nome de variável muito curto só é útil se ele tem uma história que o torna compreensível (por exemplo, i, j, e kpara os índices, dxpara uma distância ao longo de um eixo) ou um escopo que é pequeno o suficiente para todas as referências a ser visíveis ao mesmo tempo (por exemplo, , temp). Os piores nomes de variáveis ​​do mundo são coisas assim t47. ("O que isso significa e por que é diferente t46?") Graças a Deus esse estilo de nomeação foi predominante no FORTRAN, mas é aqui que o desejo de nomes de variáveis ​​mais longos está enraizado.

Como o documento original mostrou, nomes muito longos também são difíceis de ler, pois diferenças sutis internas podem ser perdidas ao se olhar para o código. (A diferença entre DistanceBetweenXAxisAbscissae& DistanceBetweenYAxisAbscissaeé realmente difícil de entender rapidamente.)

Como o NoteToSelf apontou anteriormente, os requisitos para exclusividade de um nome dependem principalmente do escopo em que o nome deve ser exclusivo. O índice de um loop de 5 linhas pode ser i; é melhor que um índice de um registro ativo que seja passado de função para função tenha um nome muito mais descritivo.

Uma variável local para uma função pode ter um pequeno nome descritivo como deltaXsem problemas. Uma variável estática delta X em um módulo deve ter um nome que distinga esse deltaX de outros deltaX no mesmo módulo, tornando-o mais longo. E uma variável delta X global deve ser tornada exclusiva em todos os módulos e em todos os outros módulos possíveis que possam ser criados, provavelmente concatenando o nome do módulo com o outro nome descritivo. Este é um dos muitos problemas com os globais; para serem úteis, os nomes devem ser longos o suficiente para dificultar a leitura.

Pelo contrário, acho que identificadores longos são piores que identificadores curtos (a menos que você esteja lidando com constantes). Usar TheVariableThatHoldsTheCapacityOfMyContainerClasstorna seu código muito mais propenso a erros do que usar Capacity.

Em si mesmos, identificadores curtos não são ruins. O objetivo de escolher bons nomes (curtos ou longos) está em serviço para esclarecer o código. A escolha de identificadores no serviço de clareza de código é mais importante do que atender a algum requisito de tamanho mínimo. Em geral, o que isso significa é escrever nomes significativos um pouco mais.

Uma observação que tive ao longo dos anos e é menos hoje do que há 10 ou 15 anos atrás. Os programadores que não podem digitar são os que lutam com unhas e dentes por nomes variáveis. Eles são os únicos com todos os nomes de variáveis ​​de 1 a 3 letras.

Portanto, meu conselho é usar um nome significativo, como muitos comentaristas disseram, e aprender a digitar. Eu tenho pensado em adicionar um teste de digitação às entrevistas, apenas para ver onde as pessoas estão, mas estou começando a ver muito menos pessoas que não escrevem à medida que os computadores se tornam uma parte maior da sociedade.

O primeiro artigo que você vincula parece interessante, mas sua conclusão é que eles não encontraram evidências significativas a favor ou contra a hipótese de que "dicas de aterramento", incluindo nomes significativos de variáveis, ajudam na compreensão do código. O olhar usado permanece o tempo como um proxy para a compreensão do código, o que é interessante, mas não um slam dunk.

Receio ter achado o segundo artigo simplesmente bobo. O primeiro problema é que os exemplos de nomes longos que eles fornecem são gratuitos, sem fornecer informações extras. Acho que todos podemos concordar que tornar um nome de variável mais longo apenas para torná-lo mais longo é estúpido. O exemplo deles de nomear uma variável distance_between_abscissae em vez de dx é um homem de palha.

Mais importante, o experimento deles é um teste de memorização simples, e não de compreensão. Ele testa a capacidade dos sujeitos de preencher partes ausentes de um nome de variável quando apresentadas em uma lista sem contexto. Sim, nomes mais longos são mais difíceis de memorizar, mas quando estou codificando não memorizo ​​nomes de variáveis, os uso para fornecer contexto. Suponho que você possa argumentar que a dificuldade de lembrar a variável longa dificulta a escrita do código, mas o código é lido com muito mais frequência do que o escrito, portanto, qual atividade deve ser otimizada?

Uma das minhas principais métricas para determinar se uma linha de código é legível ou não é quanto outro contexto de outras linhas deve ser lido para ter certeza de que você entende o que a linha está fazendo.

É fácil dizer que "qualquer pessoa deve entender que i, j e k são variáveis ​​de loop". E na maioria das vezes é realmente óbvio. Mas ainda tento ser humilde e profissional sobre isso e presumo que é fácil cometer erros ao programar. Portanto, se eu estiver fazendo um loop através de uma matriz de Grobbles, nomeará a variável de loop grobbleIndex. Eu também poderia aceitar i como uma abreviação de index. Quando você está usando ij ek, é mais difícil detectar erros, como usar o índice errado com a matriz errada e assim por diante. E fica ainda pior quando você tem um loop interno.

PS. Na época em que escrevi essa resposta, eu estava codificando algum javascript em um mini laptop de 10 "com uma tela dividida verticalmente no vim e ainda assim dediquei um tempo para nomear minhas variáveis ​​de loop rowIndex e columnIndex.

Em algumas aplicações, uma variável curta simplesmente não pode explicar os dados na variável. Curto ou longo é irrelevante. Usar uma variável mais longa não torna seu código mais lento. Certamente, é mais difícil digitar um nome de variável longo, mas pelo menos a pessoa que lê o código 6 meses depois (que pode ser você) será capaz de entender o que está acontecendo sem precisar colocar rastros, supondo que isso seja possível.

Eu acho que o ideal é que os nomes sejam descritivos, a menos que ...

A idéia de que os nomes podem (talvez deva) ser mais curtos - e, portanto, por implicação, menos descritivos - se tiverem escopo limitado é apenas uma razão para se desviar do ideal.

Pessoalmente, freqüentemente uso nomes abreviados para um pequeno número de entidades com referências repetidas. Sub-rotinas específicas do aplicativo, chamadas com frequência, por exemplo.

Eu nunca usaria nomes de identificador com menos de 4-5 caracteres, por exemplo, uma variável de loop pode ser Index ou jIndex ou kIndex, dependendo de quantos loops internos eu preciso para realizar alguma coisa, mas, para outros nomes, digamos uma "chave" que eu usaria "String LKey" ou "int LKey", "L" para local se for uma variável de método ou "F" para variável de classe privada, todos os outros identificadores como outros mencionados antes de mim devem explicar o motivo de sua existência em seu nome, caso contrário, o O escopo "identificador" é inútil, não é ?!