Aikido

Pourquoi utiliser des noms de variables descriptifs pour écrire du code auto-documenté

Lisibilité

Règle
Utilisation descriptif noms de .
Très courts noms de variables noms rendent code peu clair.

Langues prises en charge : 45+

Introduction

Les noms de variables à une seule lettre ou cryptiques forcent les lecteurs à déduire le sens du contexte au lieu de comprendre le code d'un coup d'œil. Une variable nommée d pourrait représenter une date, une durée, une distance ou des données, exigeant un effort mental pour suivre son objectif tout au long de la fonction. Des noms descriptifs comme userCreatedDate ou requestDuration rendre l'intention immédiatement claire sans surcharge cognitive.

Pourquoi c'est important

Maintenabilité du code : Les noms de variables peu clairs ralentissent la compréhension. Les développeurs passent du temps à déterminer ce que représentent x, tmp ou val au lieu de se concentrer sur la logique réelle. Une mauvaise nomenclature rend également le code plus difficile à étendre car il n'est pas clair où la nouvelle logique devrait s'intégrer ou comment les valeurs existantes sont liées les unes aux autres. De plus, les noms vagues rendent la base de code non interrogeable, car la recherche de tmp ou val ne donne aucun résultat significatif. Cela s'aggrave lors du retour au code des mois plus tard ou lorsque de nouveaux membres rejoignent l'équipe.

Introduction de bugs : Les noms ambigus augmentent le risque d'utiliser la mauvaise variable. Lorsque plusieurs variables ont des noms cryptiques similaires (d1, d2, d3), les développeurs pourraient utiliser le mauvais, introduisant des bugs subtils qui passent la revue de code car les noms ne fournissent aucune indication sémantique.

Exemples de code

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

Pourquoi c'est inexact : Noms de variables tels que u, p, d, t, et 'a' ne révèlent rien de leur objectif. Les lecteurs doivent analyser la logique de calcul pour comprendre que p est le prix, d est la remise, t est le sous-total, et a est le montant avant taxes.

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

Pourquoi c'est important : Chaque nom de variable décrit ce qu'il contient. amountAfterDiscount indique clairement l'état du calcul, taxe est sans ambiguïté, et produit et quantité révéler les entrées de la fonction sans avoir besoin de lire le corps.

Conclusion

Utilisez des noms qui révèlent l'intention sans nécessiter de contexte. Privilégiez la clarté à la concision. Les caractères supplémentaires dans totalPrice versus tp ne coûtent rien à l'exécution mais font gagner un temps considérable en compréhension.

FAQ

Des questions ?

Les noms de variables à une seule lettre sont-ils acceptables ?

Oui, dans des contextes limités. Les compteurs de boucle (i, j, k) sont conventionnels et clairs. Les paramètres de fonction lambda en programmation fonctionnelle (x => x * 2) sont acceptables lorsque l'opération est évidente. Les opérations mathématiques peuvent utiliser des noms conventionnels (x, y pour les coordonnées). Cependant, ceux-ci doivent être limités à de petites portées (quelques lignes).

Quelle devrait être la longueur des noms de variables ?

Assez long pour être clair, assez court pour être pratique. `userData` est préférable à `u` et à `dataAboutTheCurrentUserBeingProcessed`. Visez 2 à 4 mots. Si vous en avez besoin de plus, la variable pourrait représenter un concept qui mérite son propre type ou sa propre classe.

Qu'en est-il des abréviations comme btn, msg ou ctx ?

Les abréviations courantes dans votre domaine sont acceptables. ctx pour context, req pour request et res pour response sont largement compris en JavaScript. Cependant, évitez les abréviations spécifiques au projet qui ne sont pas évidentes pour les nouveaux membres de l'équipe. En cas de doute, écrivez le mot en entier.

Dois-je renommer les variables lors de la refactorisation d'ancien code ?

Oui, mais de manière stratégique. Si vous modifiez une fonction pour d'autres raisons, améliorez les noms de variables dans le cadre de cette modification. Ne créez pas de pull requests (PRs) uniquement pour renommer, à moins que les noms ne causent une confusion active ou des bugs. Utilisez les outils de refactoring de l'IDE pour vous assurer que toutes les références sont mises à jour correctement.

Comment gérer les conflits avec les mots-clés du langage ?

Ajoutez de la spécificité : userClass au lieu de class, itemType au lieu de type. Ou utilisez le contexte : userCategory, productKind. N'ajoutez jamais de chiffres (class1, class2) car cela perd son sens. La contrainte révèle souvent que vous avez de toute façon besoin d'un nom plus spécifique.

Sécurisez-vous maintenant.

Sécuriser votre code, votre cloud et votre runtime dans un système centralisé unique.
Détectez et corrigez les vulnérabilités rapidement et automatiquement.

Pas de carte de crédit requise | Résultats du scan en 32 secondes.