Payload Logo
Développeur de dos entre un fouillis de fils orange et des lignes propres et alignées
JavaScript

Auteur

Latchere Yoan

Date de publication

Un code de junior n'est pas forcément un code faux. Il fonctionne, il passe les tests, il fait ce qu'on lui demande. Ce qui change avec l'expérience, c'est la lisibilité : le code d'un développeur confirmé se lit vite, se modifie sans peur et cache moins de pièges.

Voici dix réécritures que je fais tout le temps en relecture de code. Pour chacune, j'ai vérifié que la version « propre » donne exactement le même résultat que l'ancienne.

1. Retourner directement la condition

// Avant
function majeur(age) {
if (age >= 18) {
return true;
} else {
return false;
}
}
// Après
function majeur(age) {
return age >= 18;
}

Une comparaison est déjà un booléen. Inutile de l'envelopper dans un if.

2. Sortir tôt plutôt qu'imbriquer

// Avant
function prix(user) {
if (user) {
if (user.actif) {
return user.prix;
}
}
return 0;
}
// Après
function prix(user) {
if (!user) return 0;
if (!user.actif) return 0;
return user.prix;
}

Chaque cas d'échec est traité tout de suite, et le cas normal reste à la fin, sans niveau d'indentation en plus. Plus on imbrique, plus on s'y perd.

3. Une liste plutôt qu'une chaîne de ||

// Avant
const ok = ext === "jpg" || ext === "png" || ext === "gif";
// Après
const IMG = ["jpg", "png", "gif"];
const ok = IMG.includes(ext);

Ajouter un format revient à ajouter un élément dans la liste, pas à réécrire la condition.

4. Un objet à la place d'un switch

// Avant
switch (statut) {
case "ok": c = "vert"; break;
case "ko": c = "rouge"; break;
default: c = "gris";
}
// Après
const COULEURS = { ok: "vert", ko: "rouge" };
const c = COULEURS[statut] ?? "gris";

Pour une simple correspondance clé-valeur, l'objet est plus court et supprime le risque d'oublier un break.

5. Les template literals

// Avant
const msg = "Salut " + nom + ", " + age + " ans !";
// Après
const msg = `Salut ${nom}, ${age} ans !`;

6. Nommer les nombres magiques

// Avant
const ttc = ht * 1.2;
const remise = ht * 0.1;
// Après
const TVA = 1.2;
const REMISE = 0.1;
const ttc = ht * TVA;
const remise = ht * REMISE;

Dans six mois, personne ne saura ce que représente 1.2. Un nom de constante le dit tout de suite, et un changement de taux ne demande qu'une modification.

7. Un const avec un ternaire

// Avant
let role;
if (user.admin) {
role = "admin";
} else {
role = "membre";
}
// Après
const role = user.admin ? "admin" : "membre";

Une variable qui ne change plus après sa création doit être un const. Cela évite qu'elle soit modifiée par erreur plus loin.

8. Un objet d'options plutôt que des paramètres à la suite

// Avant
const u = creer("Léa", true, 3);
// Après
const u = creer({ nom: "Léa", admin: true, niveau: 3 });

À la lecture, personne ne sait ce que true et 3 veulent dire dans le premier appel. Avec des clés nommées, l'ordre n'a plus d'importance non plus.

9. Toujours l'égalité stricte

const saisie = "";
saisie == 0; // true
saisie === 0; // false

Avec ==, JavaScript convertit avant de comparer, et une chaîne vide devient 0. Avec ===, pas de conversion, donc pas de surprise. C'est la règle que j'applique sans exception.

10. Ne jamais faire confiance à JSON.parse

// Avant
const prefs = JSON.parse(texte);
// Après
let prefs = {};
try {
prefs = JSON.parse(texte);
} catch {
// on garde les valeurs par défaut
}

Si le texte est invalide (par exemple {oups), JSON.parse lève une SyntaxError et fait tomber tout le script. Dès que la donnée vient de l'extérieur, du localStorage, d'une API ou d'un formulaire, on protège l'appel.

Ce que ça change au quotidien

Aucune de ces réécritures n'est spectaculaire. Ensemble, elles rendent un fichier plus court, plus prévisible et plus agréable à reprendre. C'est exactement ce que j'essaie d'appliquer quand je développe des sites pour mes clients : un code que la personne suivante pourra lire sans stress.

Pour continuer, tu peux tester tes réflexes avec dix quiz JavaScript qui surprennent, ou regarder comment éviter les pièges de fetch.