Aikido

Perché dovresti usare nomi di variabili descrittivi per scrivere codice auto-documentato

Leggibilità

Regola
Usa nomi di variabili descrittivi.
Nomi di variabili molto brevi rendono il codice poco chiaro.

Linguaggi supportati: 45+

Introduzione

Nomi di variabili a lettera singola o criptici costringono chi legge a dedurre il significato dal contesto anziché comprendere il codice a colpo d'occhio. Una variabile denominata d potrebbe rappresentare data, durata, distanza o dati, richiedendo uno sforzo mentale per tracciarne lo scopo all'interno della funzione. Nomi descrittivi come userCreatedDate oppure requestDuration rendono l'intento immediatamente chiaro senza alcun carico cognitivo.

Perché è importante

Manutenibilità del codice: nomi di variabili poco chiari rallentano la comprensione. Gli sviluppatori perdono tempo a capire cosa rappresentano x, tmp o val invece di concentrarsi sulla logica effettiva. Una cattiva denominazione rende inoltre il codice più difficile da estendere, poiché non è chiaro dove debba trovare spazio la nuova logica o come i valori esistenti si relazionino tra loro. Oltre a ciò, nomi vaghi rendono la codebase impossibile da ricercare, dal momento che la ricerca di tmp o val non produce risultati significativi. Questo problema si amplifica quando si ritorna sul codice mesi dopo o quando si uniscono nuovi membri al team.

Introduzione di bug: Nomi ambigui aumentano la probabilità di utilizzare la variabile sbagliata. Quando più variabili hanno nomi criptici simili (d1, d2, d3), gli sviluppatori potrebbero usare quella errata, introducendo bug subdoli che superano la code review perché i nomi non forniscono indizi semantici.

Esempi di codice

❌ Non 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;
}

Perché non è accurato: Nomi di variabili come u, p, d, t, e non rivelano nulla sul loro scopo. I lettori devono analizzare la logica di calcolo per capire che p è il prezzo, d è lo sconto, t è il subtotale e a è l'importo prima delle tasse.

✅ Conforme:

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;
}

Perché questo è importante: Ogni nome di variabile descrive chiaramente il suo contenuto. amountAfterDiscount indica chiaramente lo stato del calcolo, tax è inequivocabile e product e quantity rivela gli input della funzione senza bisogno di leggerne il corpo.

Conclusione

Usa nomi che rivelano l'intento senza richiedere contesto. Prediligi la chiarezza alla brevità. I caratteri extra in totalPrice rispetto a tp non costano nulla in termini di esecuzione, ma fanno risparmiare molto tempo nella comprensione.

FAQ

Hai domande?

I nomi di variabili a singola lettera sono mai accettabili?

Sì, in contesti limitati. I contatori dei cicli (i, j, k) sono convenzionali e chiari. I parametri delle funzioni lambda nella programmazione funzionale (x => x * 2) vanno bene quando l'operazione è ovvia. Le operazioni matematiche possono usare nomi convenzionali (x, y per le coordinate). Tuttavia, questi dovrebbero essere limitati a scope ridotti (poche righe).

‍

Quanto dovrebbero essere lunghi i nomi delle variabili?

Abbastanza lunghi da essere chiari, abbastanza brevi da essere pratici. userData è meglio di u ed è meglio di dataAboutTheCurrentUserBeingProcessed. Punta a 2-4 parole. Se te ne servono di più, la variabile potrebbe rappresentare un concetto che merita un tipo o una classe dedicata.

E per quanto riguarda le abbreviazioni come btn, msg o ctx?

Le abbreviazioni comuni nel tuo dominio sono accettabili. ctx per context, req per request e res per response sono ampiamente compresi in JavaScript. Tuttavia, evita abbreviazioni specifiche del progetto che non siano ovvie per i nuovi membri del team. Nel dubbio, scrivi la parola per esteso.

Conviene rinominare le variabili quando si fa il refactoring di vecchio codice?

Sì, ma in modo strategico. Se modifichi una funzione per altri motivi, migliora i nomi delle variabili come parte della modifica. Non creare PR solo per rinominare, a meno che i nomi non stiano causando confusione o bug evidenti. Usa gli strumenti di refactoring dell'IDE per assicurarti che tutti i riferimenti vengano aggiornati correttamente.

Come gestisco i conflitti con le parole chiave del linguaggio?

Aggiungi specificità: userClass invece di class, itemType invece di type. Oppure usa il contesto: userCategory, productKind. Non aggiungere mai numeri (class1, class2) perché in questo modo si perde il significato. Spesso questo vincolo rivela comunque la necessità di un nome più specifico.

Metti in sicurezza ora

Metti in sicurezza il tuo codice, il cloud e il runtime in un unico sistema centralizzato.
Trova e risolvi le vulnerabilità rapidamente e automaticamente.

Nessuna carta di credito richiesta | Risultati della scansione in 32 secondi.