Points clés
1. Un code propre est lisible, simple et expressif
Un code propre ressemble toujours à celui d’une personne qui prend soin de son travail.
La clarté est essentielle. Un code propre se distingue par sa lisibilité et sa simplicité. Il doit être facile à comprendre, modifier et maintenir par d’autres programmeurs. Cela passe par l’utilisation de noms clairs et significatifs, des fonctions et classes courtes et ciblées, ainsi qu’une organisation logique du code.
Un code expressif communique l’intention. Le code propre doit refléter clairement l’intention du programmeur sans nécessiter de commentaires excessifs. Cela s’obtient grâce à des noms bien choisis, des fonctions courtes qui accomplissent une tâche précise, et une structure globale limpide. Le code doit raconter une histoire, facilitant la compréhension de la logique et du rôle de chaque élément.
L’amélioration continue est indispensable. Écrire un code propre est un processus permanent qui demande une attention constante et du refactoring. Les programmeurs doivent suivre la règle des scouts : « Laissez le campement plus propre que vous ne l’avez trouvé. » Cela signifie toujours chercher à améliorer la clarté et la structure du code, même par de petits ajustements, à chaque modification ou ajout.
2. Des noms significatifs renforcent la clarté et la maintenabilité du code
Le nom d’une variable, d’une fonction ou d’une classe doit répondre à toutes les grandes questions : pourquoi elle existe, ce qu’elle fait, et comment elle est utilisée.
Choisissez des noms descriptifs. Les noms doivent être explicites et révéler l’intention derrière les variables, fonctions et classes. Évitez les noms d’une seule lettre, les abréviations obscures ou les codes cryptiques qui obligent à une interprétation mentale pour comprendre leur rôle.
Respectez les conventions de nommage. Adoptez et appliquez de manière cohérente les conventions propres à votre langage et à votre équipe. Par exemple :
- CamelCase pour les noms de classes (ex. : CustomerOrder)
- camelCase pour les variables et fonctions (ex. : totalAmount)
- MAJUSCULES pour les constantes (ex. : MAX_SIZE)
Évitez la désinformation et le bruit. Ne donnez pas de noms pouvant induire en erreur ou semer la confusion. Par exemple, évitez d’utiliser « list » dans un nom de variable si ce n’est pas réellement une liste. Supprimez aussi les mots redondants ou vides de sens comme « data » ou « info » lorsqu’ils n’apportent rien.
3. Les fonctions doivent être courtes, faire une seule chose, et opérer à un seul niveau d’abstraction
Les fonctions doivent faire une chose. Elles doivent bien la faire. Et rien d’autre.
Gardez les fonctions courtes. Idéalement, une fonction ne doit pas dépasser 20 lignes. Cela facilite sa lecture, sa compréhension et sa maintenance. Les fonctions courtes sont aussi plus simples à nommer précisément, à tester et à réutiliser.
Principe de responsabilité unique. Chaque fonction doit avoir un but clairement défini. Si une fonction fait plusieurs choses, il faut la découper en fonctions plus petites et ciblées. Cela améliore la lisibilité et rend le code plus modulaire et facile à modifier.
Niveau d’abstraction cohérent. À l’intérieur d’une fonction, toutes les opérations doivent se situer au même niveau d’abstraction. Mélanger logique de haut niveau et détails bas niveau complique la compréhension et la maintenance. Utilisez la technique de refactoring « Extraire une méthode » pour séparer les différents niveaux dans des fonctions distinctes.
4. Les commentaires doivent être rares et vraiment nécessaires
Le bon usage des commentaires est de compenser notre incapacité à nous exprimer clairement dans le code.
Le code doit être auto-explicatif. Un code bien écrit, avec des noms clairs et une structure soignée, supprime souvent le besoin de commentaires. Avant d’en ajouter, demandez-vous si vous ne pouvez pas refactorer le code pour mieux faire passer l’intention.
Utilisez les commentaires avec discernement. Les bons commentaires expliquent pourquoi quelque chose est fait, pas comment. Ils apportent un contexte ou une précision qu’on ne peut pas exprimer uniquement par le code. Par exemple :
- Commentaires légaux (copyright, licences)
- Explications d’intention ou d’algorithmes
- Avertissements sur les conséquences
- TODO (à utiliser avec parcimonie)
Évitez les commentaires redondants ou trompeurs. Ne rédigez pas de commentaires qui répètent ce que le code dit clairement. Les commentaires obsolètes ou erronés sont pires que l’absence de commentaires, car ils induisent en erreur. Pensez à les revoir et à les mettre à jour régulièrement avec le code.
5. Un bon formatage améliore la lisibilité du code
Le formatage du code est une question de communication, et la communication est la priorité du développeur professionnel.
Un style cohérent est important. Établissez et respectez un style de formatage uniforme dans tout votre code. Cela inclut :
- L’indentation
- Les sauts de ligne
- Le placement des accolades
- Les espaces autour des opérateurs et mots-clés
Formatage vertical. Organisez le code verticalement pour faciliter la lecture :
- Regroupez les concepts liés
- Séparez les concepts sans lien
- Déclarez les variables près de leur utilisation
- Placez les fonctions dépendantes à proximité
Formatage horizontal. Gardez les lignes raisonnablement courtes (généralement entre 80 et 120 caractères) pour éviter le défilement horizontal. Coupez les longues instructions en plusieurs lignes de façon logique. Utilisez les espaces pour séparer les blocs logiques dans une même ligne.
6. Objets et structures de données ont des rôles différents
Les objets cachent leurs données derrière des abstractions et exposent des fonctions qui opèrent sur ces données. Les structures de données exposent leurs données et n’ont pas de fonctions significatives.
Objets vs structures de données. Les objets encapsulent les données et exposent un comportement via des méthodes. Ils sont adaptés pour ajouter de nouveaux types (classes) sans modifier le comportement existant. Les structures de données, quant à elles, exposent leurs données sans comportement notable. Elles conviennent pour ajouter de nouveaux comportements sans changer les types existants.
Choisissez la bonne approche. Utilisez les objets lorsque vous souhaitez ajouter fréquemment de nouveaux types tout en conservant un comportement stable. Privilégiez les structures de données lorsque vous voulez ajouter souvent de nouveaux comportements tout en gardant les types stables. Comprendre cette distinction aide à concevoir des systèmes plus flexibles et maintenables.
Loi de Déméter. Pour les objets, respectez la Loi de Déméter : une méthode ne doit appeler que les méthodes de :
- L’objet lui-même
- Ses paramètres
- Les objets qu’elle crée
- Ses composants directs
Ce principe réduit le couplage entre les différentes parties d’un système.
7. La gestion des erreurs doit être propre et informative
La gestion des erreurs est importante, mais si elle obscurcit la logique, c’est une erreur.
Privilégiez les exceptions aux codes d’erreur. Les exceptions offrent une manière plus propre de gérer les erreurs que les codes d’erreur traditionnels. Elles séparent la logique de gestion des erreurs du code principal, ce qui rend les deux plus clairs et plus faciles à maintenir.
Créez des messages d’erreur informatifs. Les messages d’erreur doivent fournir suffisamment de contexte pour comprendre ce qui a mal tourné et où. Incluez des détails pertinents tels que :
- L’opération tentée
- L’erreur spécifique survenue
- Les valeurs ou états pertinents
Écrivez d’abord les blocs try-catch-finally. Lorsque vous écrivez du code susceptible de lancer des exceptions, commencez par rédiger les blocs try-catch-finally. Cela garantit que le code est résilient face aux erreurs dès le départ et que les cas d’erreur sont bien pris en compte.
8. Les tests unitaires sont cruciaux pour maintenir un code propre
Le code de test est aussi important que le code de production.
Écrivez les tests en premier. Suivez la démarche du développement piloté par les tests (TDD) :
- Écrivez un test qui échoue
- Écrivez le code minimum pour réussir le test
- Refactorez le code en gardant le test réussi
Cette méthode garantit que votre code est testable dès le départ et favorise une bonne conception.
Gardez les tests propres. Appliquez aux tests les mêmes standards de propreté qu’au code de production. Des tests propres sont :
- Lisibles
- Maintenables
- Fiables
Respectez les principes F.I.R.S.T pour les tests :
- Fast (rapides) : les tests doivent s’exécuter vite
- Independent (indépendants) : les tests ne doivent pas dépendre les uns des autres
- Repeatable (répétables) : les tests doivent pouvoir être rejoués dans n’importe quel environnement
- Self-Validating (auto-validants) : les tests doivent produire un résultat booléen (succès/échec)
- Timely (opportuns) : les tests doivent être écrits juste avant le code de production
9. Les classes doivent être petites, ciblées, et respecter le principe de responsabilité unique
La première règle des classes est qu’elles doivent être petites. La deuxième règle est qu’elles doivent être encore plus petites.
Gardez les classes ciblées. Une classe doit avoir une responsabilité unique et bien définie. Si vous ne pouvez pas décrire l’objectif d’une classe en une vingtaine de mots sans utiliser « et » ou « ou », elle fait probablement trop de choses.
Visez une forte cohésion. Les méthodes et variables d’une classe doivent être étroitement liées et collaborer pour remplir la responsabilité de la classe. Une faible cohésion indique souvent qu’une classe est surchargée et devrait être divisée.
Principe ouvert-fermé. Concevez les classes pour qu’elles soient ouvertes à l’extension mais fermées à la modification. Cela passe souvent par l’usage d’abstractions et d’interfaces permettant d’ajouter des fonctionnalités sans changer le code existant.
10. La concurrence nécessite une conception et une mise en œuvre rigoureuses
Écrire des programmes concurrents propres est difficile — très difficile.
Comprenez les défis de la concurrence. La programmation concurrente introduit des complexités telles que :
- Conditions de course
- Interblocages
- Problèmes de vivacité
- Impacts sur les performances
Isolez le code lié à la concurrence. Séparez le code qui gère la concurrence. Cela facilite la compréhension, les tests et la maintenance des parties concurrentes et non concurrentes du système.
Utilisez des bibliothèques et frameworks éprouvés. Privilégiez les bibliothèques et frameworks de concurrence bien testés (par exemple java.util.concurrent en Java) plutôt que d’implémenter vous-même des mécanismes bas niveau. Ces outils sont optimisés et éprouvés pour les patterns courants.
Rédigez des tests rigoureux. Tester du code concurrent est complexe mais indispensable. Écrivez des tests qui :
- Créent plusieurs threads
- Varient le timing et l’ordonnancement
- S’exécutent de nombreuses fois pour détecter les problèmes intermittents
- Utilisent des outils comme les analyseurs statiques et les détecteurs de conditions de course pour identifier les bugs potentiels
Dernière mise à jour:
FAQ
What's Clean Code: A Handbook of Agile Software Craftsmanship about?
- Focus on Software Craftsmanship: The book emphasizes the importance of writing clean, maintainable code as a hallmark of professionalism in software development.
- Principles and Practices: It outlines various principles, patterns, and practices that help programmers write code that is not only functional but also easy to read and understand.
- Real-World Examples: Numerous examples of both good and bad code are included, demonstrating how to transform messy code into clean code through refactoring and disciplined practices.
Why should I read Clean Code by Robert C. Martin?
- Improve Coding Skills: Reading the book can significantly enhance your programming skills by teaching you how to write code that is easier to maintain and understand.
- Professional Development: It is a valuable resource for anyone looking to advance their career in software development, instilling a mindset of craftsmanship and quality.
- Practical Advice: The book provides practical advice that can be applied immediately in your coding practices, making it a useful guide for both novice and experienced programmers.
What are the key takeaways of Clean Code?
- Meaningful Names: The book stresses the importance of using intention-revealing names for variables, functions, and classes to enhance code readability and maintainability.
- Small Functions: Functions should be small and focused on a single task, adhering to the principle of "Do One Thing" to improve clarity and reduce complexity.
- Error Handling: Martin advocates for using exceptions rather than return codes for error handling, which helps keep the main logic of the code clean and unobscured.
What are the best quotes from Clean Code and what do they mean?
- "Clean code is a matter of discipline.": This quote emphasizes that writing clean code requires consistent effort and adherence to best practices, rather than relying on luck or talent alone.
- "Comments do not make up for bad code.": This highlights the idea that if code is poorly written, no amount of commenting can compensate for its lack of clarity and structure.
- "Leave the campground cleaner than you found it.": This metaphor encourages developers to improve the codebase with every change, ensuring that the code remains clean and maintainable over time.
How does Clean Code define clean code?
- Readable and Understandable: Clean code is defined as code that is easy to read and understand, allowing other developers to quickly grasp its purpose and functionality.
- Minimal Complexity: It should have minimal complexity, with each function and class focused on a single responsibility, making it easier to test and maintain.
- Well-Structured: Clean code is well-structured, following consistent formatting and naming conventions that enhance its clarity and reduce the cognitive load on the reader.
What is the Boy Scout Rule in Clean Code?
- Continuous Improvement: The Boy Scout Rule states that developers should "leave the campground cleaner than you found it," meaning that every time you work on code, you should strive to improve it.
- Small Changes Matter: This can be as simple as renaming a variable for clarity or refactoring a small function, which contributes to the overall cleanliness of the codebase.
- Professional Responsibility: Adhering to this rule reflects a professional attitude towards code quality and maintenance, fostering a culture of continuous improvement within a team.
What is the Single Responsibility Principle (SRP) in Clean Code?
- Definition of SRP: The SRP states that "a class should have one, and only one, reason to change." This means that each class should focus on a single responsibility or functionality.
- Benefits of SRP: Adhering to SRP leads to better organization of code, making it easier to understand, test, and maintain. It reduces the risk of changes in one area affecting unrelated parts of the code.
- Implementation Guidance: Martin provides practical advice on how to identify responsibilities and refactor classes to adhere to SRP, ensuring that code remains clean and manageable.
How does Clean Code address error handling?
- Use Exceptions: The book advocates for using exceptions rather than return codes for error handling, which helps keep the main logic of the code clean and unobscured.
- Separation of Concerns: Error handling should be separated from the main logic of the code, allowing developers to focus on the primary functionality without being bogged down by error-checking clutter.
- Provide Context: Exceptions should provide enough context to understand the source and nature of the error, making it easier to diagnose and fix issues when they arise.
What role does testing play in Clean Code?
- Foundation of Clean Code: Testing is considered a fundamental discipline in writing clean code. It ensures that the code behaves as expected and helps catch issues early in the development process.
- Fast and Reliable Tests: The book emphasizes that tests should be fast and reliable to encourage frequent execution. This helps maintain a clean codebase and reduces the risk of introducing bugs.
- Self-Validating Tests: Tests should be designed to be self-validating, meaning they should clearly indicate whether the code is functioning correctly. This reduces ambiguity and increases confidence in the code.
How does Clean Code suggest handling dependencies?
- Dependency Inversion Principle (DIP): The book explains that "high-level modules should not depend on low-level modules. Both should depend on abstractions." This principle encourages the use of interfaces and abstract classes to reduce coupling.
- Use of Dependency Injection: Martin recommends using dependency injection to manage dependencies, allowing for more flexible and testable code. This approach decouples the creation of dependencies from their usage.
- Benefits of Managing Dependencies: By managing dependencies effectively, developers can create systems that are easier to maintain and extend, leading to cleaner and more robust code.
What are some common code smells identified in Clean Code?
- Duplicated Code: This is a major code smell that indicates a lack of abstraction. The book advises eliminating duplication to improve maintainability and reduce errors.
- Long Methods: Methods that are too long can be difficult to understand and maintain. The book suggests breaking them down into smaller, more manageable functions.
- Excessive Comments: While comments can be helpful, excessive or redundant comments often indicate that the code itself is not clear. The goal should be to write self-explanatory code that requires minimal comments.
How can I apply the principles from Clean Code in my own projects?
- Start with Small Changes: Begin by applying the principles of clean code to small sections of your codebase. Refactor one class or function at a time to improve readability and maintainability.
- Write Tests First: Adopt Test-Driven Development (TDD) practices by writing tests before implementing new features. This ensures that your code is always covered by tests and helps maintain quality.
- Regularly Refactor: Make refactoring a regular part of your development process. Continuously look for opportunities to improve code structure and eliminate duplication, keeping your codebase clean and efficient.
Avis
Clean Code est largement reconnu comme une lecture incontournable pour les développeurs logiciels, apportant des éclairages précieux sur la rédaction d’un code lisible et facile à maintenir. Salué pour ses conseils pratiques concernant les conventions de nommage, la conception des fonctions et les tests, certains lecteurs ont toutefois reproché au livre son orientation trop centrée sur Java ainsi que ses recommandations parfois jugées excessives. Les études de cas présentées ont suscité des avis partagés : certains les ont trouvées utiles, tandis que d’autres y ont vu moins d’intérêt. Malgré ces limites, de nombreux développeurs considèrent cet ouvrage comme un passage obligé qui a profondément amélioré leurs pratiques de codage et leur compréhension de l’artisanat logiciel.
Similar Books
