Aikido

Por que você deve usar nomes de variáveis descritivos para escrever código autodocumentado

Legibilidade

Regra
Utilização descritivo nomes .
Muito curtos nomes de variáveis . tornam o código pouco claro.

Idiomas suportados: 45+

Introdução

Nomes de variáveis de uma única letra ou crípticos forçam os leitores a deduzir o significado do contexto, em vez de entender o código rapidamente. Uma variável chamada d poderia representar data, duração, distância ou dados, exigindo esforço mental para rastrear seu propósito ao longo da função. Nomes descritivos como userCreatedDate ou requestDuration deixar a intenção imediatamente clara sem sobrecarga cognitiva.

Por que isso importa

Manutenibilidade do código: Nomes de variáveis pouco claros atrasam a compreensão. Desenvolvedores gastam tempo descobrindo o que x, tmp ou val representam, em vez de focar na lógica real. Nomes ruins também tornam o código mais difícil de estender, pois não fica claro onde a nova lógica deve se encaixar ou como os valores existentes se relacionam. Além disso, nomes vagos tornam a base de código inpesquisável, já que a busca por tmp ou val não retorna resultados significativos. Isso se agrava ao retornar ao código meses depois ou quando novos membros da equipe se juntam.

Introdução de bug: Nomes ambíguos aumentam a chance de usar a variável errada. Quando múltiplas variáveis têm nomes crípticos semelhantes (d1, d2, d3), desenvolvedores podem usar o errado, introduzindo bugs sutis que passam pela revisão de código porque os nomes não fornecem pistas semânticas.

Exemplos de código

❌ Não-conforme:

function calcAmt(u, qty) {
    const p = u.prc;
    const d = u.disc || 0;
    const t = p * qty;
    const a = t - (t * d);
    const tx = a * 0.08;
    return a + tx;
}

Por que é impreciso: Nomes de variáveis como u, p, d, t, e 'a' não revelam nada sobre seu propósito. Os leitores devem rastrear a lógica de cálculo para entender que p é preço, d é o desconto, t é subtotal, e a é o valor antes dos impostos.

✅ Compatível:

function calculateOrderAmount(product, quantity) {
    const price = product.price;
    const discount = product.discount || 0;
    const subtotal = price * quantity;
    const amountAfterDiscount = subtotal - (subtotal * discount);
    const tax = amountAfterDiscount * 0.08;
    return amountAfterDiscount + tax;
}

Por que isso importa: Cada nome de variável descreve o que ela contém. amountAfterDiscount indica claramente o estado do cálculo, imposto é inequívoco, e produto e quantidade revelar as entradas da função sem a necessidade de ler o corpo.

Conclusão

Use nomes que revelem a intenção sem exigir contexto. Priorize a clareza em vez da brevidade. Os caracteres extras em preçoTotal versus tp não custam nada em execução, mas economizam um tempo significativo na compreensão.

FAQs

Dúvidas?

Nomes de variáveis de uma única letra são aceitáveis?

Sim, em contextos limitados. Contadores de loop (i, j, k) são convencionais e claros. Parâmetros de função lambda em programação funcional (x => x * 2) são aceitáveis quando a operação é óbvia. Operações matemáticas podem usar nomes convencionais (x, y para coordenadas). No entanto, estes devem ser limitados a escopos pequenos (poucas linhas).

Qual o comprimento ideal para nomes de variáveis?

Longo o suficiente para ser claro, curto o suficiente para ser prático. `userData` é melhor que `u` e melhor que `dataAboutTheCurrentUserBeingProcessed`. Procure por 2-4 palavras. Se precisar de mais, a variável pode representar um conceito que merece seu próprio tipo ou classe.

E quanto a abreviações como btn, msg ou ctx?

Abreviações comuns em seu domínio são aceitáveis. ctx para context, req para request e res para response são amplamente compreendidos em JavaScript. No entanto, evite abreviações específicas do projeto que não sejam óbvias para novos membros da equipe. Em caso de dúvida, escreva por extenso.

Eu deveria renomear variáveis ao refatorar código antigo?

Sim, mas estrategicamente. Ao modificar uma função por outros motivos, melhore os nomes das variáveis como parte da mudança. Não crie PRs apenas para renomear, a menos que os nomes estejam causando confusão ativa ou bugs. Use ferramentas de refatoração da IDE para garantir que todas as referências sejam atualizadas corretamente.

Como lidar com conflitos com palavras-chave da linguagem?

Adicione especificidade: userClass em vez de class, itemType em vez de type. Ou use o contexto: userCategory, productKind. Nunca anexe números (class1, class2), pois isso perde o significado. A restrição geralmente revela que você precisa de um nome mais específico de qualquer forma.

Fique seguro agora

Proteja seu código, Cloud e runtime em um único sistema centralizado.
Encontre e corrija vulnerabilidades rapidamente de forma automática.

Não é necessário cartão de crédito | Resultados da varredura em 32 segundos.