Code propre en JavaScript : guide pour ceux qui écrivent pour les humains

Pourquoi le « code propre » n'est pas une question d'esthétique, mais d'argent et de temps

Imaginez que vous ouvrez un projet JavaScript écrit par quelqu'un d'autre. Les variables s'appellent a, b, x1. Une fonction de 300 lignes. L'imbrication des conditions comme une poupée russe. Cela vous dit quelque chose ? Si vous avez déjà maudit un tel « auteur », alors vous comprenez déjà pourquoi le code propre est nécessaire.

Le code propre en JavaScript n'est pas une mode ni un caprice de perfectionniste. C'est un outil qui économise des heures de débogage, simplifie l'intégration des nouveaux arrivants et réduit le coût de maintenance du projet. Dans cet article, nous allons détailler des règles et techniques concrètes qui vous aideront à écrire un code compréhensible non seulement par la machine, mais aussi par l'humain.

Règle n°1 : Les noms de variables et de fonctions doivent parler d'eux-mêmes

L'erreur la plus courante des débutants est d'utiliser des noms courts et insignifiants. Mauvais exemple :

let d = new Date();\nlet n = d.getDay();\nlet r = n === 0 || n === 6 ? 'Week-end' : 'Jour de semaine';\nconsole.log(r);\n

Bon exemple :

const currentDate = new Date();\nconst dayOfWeek = currentDate.getDay();\nconst isWeekend = dayOfWeek === 0 || dayOfWeek === 6;\nconst dayType = isWeekend ? 'Week-end' : 'Jour de semaine';\nconsole.log(dayType);\n

La différence est évidente. Dans la deuxième version, on comprend immédiatement ce que fait le code, sans commentaires supplémentaires. Conseil : utilisez des noms pour les variables et des verbes pour les fonctions. Par exemple : getUserData(), calculateTotal(), isValidEmail().

Comment éviter les « nombres magiques » ?

Les nombres magiques sont des chiffres dont le sens est incompréhensible sans contexte. Utilisez des constantes à la place :

// Mauvais\nif (user.role === 1) { ... }\n\n// Bon\nconst ROLE_ADMIN = 1;\nif (user.role === ROLE_ADMIN) { ... }\n

Règle n°2 : Les fonctions doivent être petites et ne faire qu'une seule chose

Le principe de responsabilité unique (Single Responsibility) s'applique non seulement aux classes, mais aussi aux fonctions. Si une fonction fait trois choses, elle doit être divisée en trois fonctions. Mauvais exemple :

function processOrder(order) {\n    // Validation\n    if (!order.items || order.items.length === 0) {\n        throw new Error('Panier vide');\n    }\n    // Calcul de la réduction\n    let discount = 0;\n    if (order.total > 1000) {\n        discount = 0.1;\n    }\n    // Envoi d'email\n    sendEmail(order.email, 'Votre commande est acceptée');\n    return order.total - order.total * discount;\n}\n

Bon exemple (refactoring) :

function validateOrder(order) {\n    if (!order.items || order.items.length === 0) {\n        throw new Error('Panier vide');\n    }\n}\n\nfunction calculateDiscount(total) {\n    return total > 1000 ? 0.1 : 0;\n}\n\nfunction notifyCustomer(email) {\n    sendEmail(email, 'Votre commande est acceptée');\n}\n\nfunction processOrder(order) {\n    validateOrder(order);\n    const discount = calculateDiscount(order.total);\n    notifyCustomer(order.email);\n    return order.total - order.total * discount;\n}\n

Cette structure permet de tester facilement chaque partie séparément et de modifier la logique sans affecter le reste du code.

Règle n°3 : Évitez les imbrications profondes

Plus il y a de niveaux d'imbrication (if dans if dans for), plus le code est difficile à lire. Utilisez le retour anticipé (early return) et les clauses de garde.

// Mauvais\nfunction getUserDisplayName(user) {\n    if (user) {\n        if (user.name) {\n            if (user.name.length > 0) {\n                return user.name;\n            }\n        }\n    }\n    return 'Anonyme';\n}\n\n// Bon\nfunction getUserDisplayName(user) {\n    if (!user || !user.name || user.name.length === 0) {\n        return 'Anonyme';\n    }\n    return use