💡 Règles de codage pour de la clarté
Que vous soyez un développeur solo ou membre d'une équipe de choc, coder ne se résume pas à "faire en sorte que ça marche". Un code de qualité se lit comme un livre : avec fluidité et clarté.
Voici quelques règles pour transformer votre code en un chef-d'œuvre de lisibilité et de maintenance.
🧱 1. La taille des procédures : La règle du "Un Seul Job"
- ❌ À éviter : les fonctions "poubelles" (aussi appelées God Functions) qui font tout : valider, calculer, envoyer, enregistrer...
- 📏 Limite physique : une fonction ne devrait pas dépasser 20 à 30 lignes.
- 🎯 Principe SRP : une fonction = une responsabilité.
- 🧠 Test de l'explication : si vous ne pouvez pas décrire la fonction sans utiliser le mot "et", elle doit être découpée.
📝 2. Le Nommage : Soyez explicite, pas mystérieux
- 🔤 Variables : utilisez des noms descriptifs (
utilisateurActifplutôt queua). - 🔧 Fonctions : commencez par un verbe d’action (
calculerTotalTVA()au lieu detva()). - 📐 Standardisation : adoptez une convention (
camelCase,snake_case, etc.) et appliquez-la partout.
📐 3. L'indentation et l'aération
- 🪜 L'indentation : elle structure la logique et prévient les bugs (ex: boucles mal fermées).
- 🌬️ Les espaces blancs : laissez respirer votre code avec des lignes vides entre les blocs logiques.
💬 4. Les commentaires : Pourquoi, pas Comment
- 🚫 Mauvais :
i = i + 1 // incrémente i - ✅ Bon :
// On passe à la page suivante suite à la validation du formulaire
➡️ Le code explique comment il fait, le commentaire doit expliquer pourquoi il le fait (décisions métier, cas complexes...)
🏕️ 5. La règle du Boy-Scout
Appliquez ce principe simple :
“Laissez le code dans un état un peu plus propre que celui dans lequel vous l'avez trouvé.”
Vous corrigez un bug ? Profitez-en pour :
- Renommer une variable mal nommée
- Découper une fonction trop longue
- Ajouter un commentaire utile
📊 En résumé : Les chiffres à retenir
| Élément | Règle d’or |
|---|---|
| Longueur de fonction | < 30 lignes |
| Nombre d’arguments | 3 maximum (au-delà : passer un objet) |
| Imbrication if/switch | 2 à 3 niveaux max (utiliser des early returns) |
“N'importe quel idiot peut écrire du code qu'un ordinateur comprend. Les bons programmeurs écrivent du code que les humains comprennent.”
— Martin Fowler
#CleanCode #Refactoring #BonnesPratiques #CodingTips #SoftwareCraftsmanship #Lisibilité #Développement #BoyScoutRule