---
name: clean-code
description: Applique les sept principes de Clean Code, le manuel illustré (nommage, petites fonctions, guard clauses, zéro nombre magique, DRY raisonné, règle du campement, KISS/YAGNI) à tout code écrit, modifié ou revu. Utiliser avant d'écrire du code et pendant les revues.
---

# Clean Code, le manuel

Tu écris du code qui sera lu par des humains. Ces règles conditionnent la
façon dont tu conçois, écris et retouches le code, dans tout langage.

## 1. Nommer, c'est déjà concevoir
- Jamais de `x`, `tmp`, `data`, `result`, `handler` ou `manager` nus.
- Un nom dit ce que la chose EST, son unité et son intention :
  `joursDepuisDeploiement`, pas `d`. `SECONDES_PAR_SEMAINE`, pas `604800`.
- Si tu hésites longtemps sur un nom, le signal est ailleurs : la
  conception n'est pas claire. Repense le découpage avant de baptiser.
- Respecte la langue et les conventions de nommage du projet existant.

## 2. Une fonction, une idée
- Si le nom juste d'une fonction contient « et », découpe-la.
- Une fonction se lit comme une phrase : l'orchestration en haut,
  les détails dans des fonctions nommées en dessous.
- Ne découpe pas mécaniquement au nombre de lignes : découpe aux
  frontières des idées.

## 3. Sortir tôt (guard clauses)
- Traite d'abord les cas qui ne concernent pas la suite, et
  débarrasse-t'en par un `return` immédiat.
- Le chemin nominal se lit à plat, au niveau d'indentation minimal.
- Plus de deux niveaux d'imbrication : restructure.

## 4. Aucun nombre magique
- Toute valeur littérale posée nue dans une logique devient une
  constante nommée qui dit son unité et sa raison d'être.
- Une constante bien nommée est un commentaire que le compilateur vérifie.

## 5. DRY raisonné : la copie finit par mentir
- Deux occurrences du même SAVOIR (une règle métier, un calcul, un
  format) : extrais-le à un seul endroit.
- Ne fusionne pas deux bouts de code qui se ressemblent par coïncidence :
  DRY porte sur le savoir, pas sur les caractères. En cas de doute,
  attendre la troisième occurrence est acceptable ; copier-coller une
  règle métier ne l'est jamais.

## 6. La règle du campement
- Chaque intervention laisse le fichier un peu plus propre : un nom
  louche renommé, un commentaire mort supprimé, un carreau ressoudé.
- MAIS : jamais de refonte non demandée. Le nettoyage opportuniste est
  petit, local, sûr, et séparé de la fonctionnalité dans l'historique
  quand c'est possible.

## 7. KISS et sa cousine YAGNI
- La solution la plus simple qui répond au besoin réel gagne. Toujours.
- Pas d'abstraction, de paramètre, de couche ou d'interface pour un
  besoin imaginé. La complexité se justifie le jour où le besoin existe.
- Si ta réponse introduit une factory, une stratégie ou un registre pour
  un besoin qui tient en une fonction : recommence.

## Les commentaires (règle transverse)
- Un commentaire dit POURQUOI, jamais QUOI : le quoi, c'est le code
  bien nommé qui le dit.
- Interdits : les commentaires qui paraphrasent la ligne, qui narrent
  l'historique des modifications, ou qui justifient le changement au
  relecteur.

## Avant de rendre ton travail, vérifie
1. Chaque nom se comprend sans lire son implémentation.
2. Aucune fonction ne cache plusieurs idées sans titre.
3. Le chemin nominal se lit à plat.
4. Aucun littéral inexpliqué.
5. Aucun savoir dupliqué.
6. Le fichier est au moins aussi propre qu'avant ton passage.
7. Rien n'a été construit « au cas où ».