🧹Clean Code de Robert C. Martin - Résumé express + exemples

Le livre Clean Code écrit par Robert C. Martin est une référence pour écrire un code de qualité : lisible, cohérent et facile à maintenir. Je l'ai découvert suite à une recommandation sur une chaîne YT, voyons ensemble ces grands principes !

🗒️Sommaire

• Lisibilité et clarté
• Petites fonctions, une seule responsabilité
• Limiter la taille des fonctions
• Éviter la duplication (DRY)
• Commenter, oui, mais coder pour ne pas avoir à le faire
• Structure logique du code
• Code modulaire et testable
• Gestion des erreurs

Lisibilité et clarté

Le nommage des variables et fonctions doivent être explicites ! En entreprise, dans un projet coconstruit : le code doit être facilement compréhensible par un autre développeur. On laisse les abréviations et le freestyle pour les projets personnels (et encore..).

❌

const d = new Date()

✅

const currentDate = new Date()

Petites fonctions, une seule responsabilité

Une fonction doit faire une seule chose et bien la faire (Single Responsibility Principle). C'est plus facile à tester et comprendre.

❌

function registerUser(user) {
  if (!user.email.includes('@')) {
    throw new Error('Email invalide')
  }

  database.save(user)

  sendWelcomeEmail(user.email, 'Bienvenue !')
}

✅

function isValidEmail(email) {
  return email.includes('@')
}

function saveUser(user) {
  database.save(user)
}

function sendWelcomeEmail(email) {
  sendEmail(email, 'Bienvenue !')
}

function registerUser(user) {
  if (!isValidEmail(user.email)) {
    throw new Error('Email invalide')
  }

  saveUser(user);
  sendWelcomeEmail(user.email)
}

Ici chaque fonction est correctement nommée, gère une chose et est réutilisable.

Limiter la taille des fonctions

On limite le nombre de paramètres, on essaie de réduire le nombre de caractères (👋 coucou les ternaires et leurs amis) tant que ça n'entache pas sa lisibilité. Une fonction doit tenir sur quelques lignes et exprimer une seule intention "lisibles de haut en bas, comme une histoire".

❌

function calculateDiscount(price, isMember, code) {
  return price * (1 - Math.min((isMember ? 0.1 : 0) + (code === 'VIP' ? 0.2 : 0), 0.3))
}

Ça tient sur une ligne mais au premier coup d'oeil on ne comprend rien et en plus de ça la fonction gère plusieurs responsabilités.
✅

function getDiscount(isMember, code) {
  const member = isMember ? 0.1 : 0
  const promo = code === 'VIP' ? 0.2 : 0
  return Math.min(member + promo, 0.3)
}

function calculateDiscount(price, isMember, code) {
  return price * (1 - getDiscount(isMember, code))
}

Deux fonctions mais elles sont concises et explicites 👌.

Eviter la duplication (DRY)

Le principe DRY (ou** Don't Repeat Yourself*) est distillé tout du long du bouquin. Le concept est simple : **factoriser le code* pour ne pas avoir plusieurs fois la même logique. Mais parfois (et surtout sur un grand projet) on ne se rend pas compte de ces duplications. Les signes qui doivent vous alerter sont les suivants :

• vous copiez/collez plusieurs fois le même bout de code pour l'intégrer dans différents fichiers.
• certaines fonctions font la même chose - à une ou deux lignes près.
• la logique n'est pas centralisée et vous intégrez un bout de code dans plusieurs fonctions.
• l'impression du déjà vu.

❌

function getAdminEmails(users) {
  return users.filter(u => u.role === 'admin').map(u => u.email)
}

function getUserEmails(users) {
  return users.filter(u => u.role === 'user').map(u => u.email)
}

✅

function getEmailsByRole(users, role) {
  return users.filter(u => u.role === role).map(u => u.email)
}

Commenter, oui, mais coder pour ne pas avoir à le faire

Un code bien écrit doit être auto documenté. Les commentaires ne doivent pas compenser un code confus (revoir les points précédents). Un code inutile commenté ? autant le supprimer ! Mea-culpa, je laisse souvent des bouts de code commentés pour diverses raisons :

• j'ai mis du temps à le faire ou à comprendre comment le faire et j'ai peur de le perdre.
• c'est le code d'un autre développeur et j'ai du mal à supprimer ce qui n'a pas été écrit par moi-même.
• comme ma mère j'utilise la carte joker du "au cas où". Mais si besoin, le versionnage de Git est là ! ❌

// const isDebug = true

❌

// Cette fonction vérifie si un utilisateur est admin
function checkUserStatus(user) {
  return user.isActive && user.points > 1000
}

✅

function isAdminUser(user) {
  return user.isActive && user.points > 1000
}

Garder une structure logique du code

Que ce soit au sein du projet et la façon dont sont architecturés les fichiers entre eux et correctement séparer les blocs à l'intérieur d'un fichier. Voici un bon exemple :

✅

// constantes
const TAX_RATE = 0.2

// fonctions utilitaires
function applyTax(price) {
  return price + price * TAX_RATE
}

function formatPrice(price) {
  return `${price.toFixed(2)} €`
}

// fonction principale
function displayTotal(price) {
  const taxedPrice = applyTax(price)
  console.log(formatPrice(taxedPrice))
}

// export éventuel
export { displayTotal }

Ecrire un code modulaire et testable

Ce chapitre rejoint le point DRY et la taille optimale d'une fonction. En ayant plusieurs unités indépendantes on peut plus facilement comprendre, réutiliser et tester le code.

Gérer les erreurs proprement

Une bonne gestion des erreurs rend le code plus fiable et ça passe par plusieurs bonnes pratiques :

• utiliser des exceptions (interrompt l'exécution du code) à la place de codes d'erreur cachés.
• être explicite : n’attrape pas une erreur pour la faire disparaître.
• isoler la validation permet de tester les erreurs facilement.
• créer des erreurs personnalisées pour les cas métier spécifiques. ❌

function register(user) {
  if (!user.email.includes('@')) return false
}

Ce bout de code est "silencieux", peu clair.
✅

function validateEmail(email) {
  if (!email.includes('@')) throw new Error('Email invalide')
}

function register(user) {
  validateEmail(user.email);
  // suite du process..
}

Ici on sépare la validation de l'enregistrement et on a une erreur claire.

Et Voilà, tes collègues et ton futur toi te remercient pour ce code de qualitey que tu es prêt à programmer; car le clean code sert tout le monde :)