Clean Code

Robert C. Martin (Uncle Bob) has been a programmer and software development expert since 1970. He is founder of Uncle Bob Consulting, LLC, and cofounder with his son Micah Martin of The Clean Coders LLC. Martin has published dozens of articles in various trade journals and is a regular speaker at international conferences and trade shows. He is the author of many books, including Agile Software Development: Principles, Patterns, and Practices; UML for Java Programmers; Clean Code; The Clean Coder; Clean Architecture; Clean Agile; Clean Craftsmanship; and Functional Design. Martin served for three years as editor-in-chief of the C++ Report and as the first chairman of the Agile Alliance.

• Foreword xixIntroduction xxvIntroduction (from Long Ago) xxixAbout the Author xxxiChapter 1: Clean Code 1There Will Be Code 2Bad Code 3The Art of Clean Code 5Putting All This Together 9We Read More Than We Write 13The Boy Scout Rule 14Part I: Code 17Chapter 2: Clean That Code! 19The Cleaning Process 30Conclusion 37Postscript: Future Bob Playing with Grok3 37Postscript Conclusion 40Chapter 3: First Principles 41Everything Small, Well Named, Organized, and Ordered 42A More Significant Example 44A Final Thought 68Chapter 4: Meaningful Names 71Use Intention-Revealing Names 72Final Words 87Chapter 5: Comments 89Compensating for Failure 90Good Comments 92Bad Comments 97Conclusion 115Chapter 6: Formatting 117The Purpose of Formatting 118Vertical Formatting 118Horizontal Formatting 127Team Rules 132Uncle Bob's Formatting Rules 133Chapter 7: Clean Functions 137Small! 138Reading Code from Top to Bottom: The Stepdown Rule 140Switch Statements 142Clean Functions: A Deeper Look 144Conclusion 157Chapter 8: Function Heuristics 159Function Arguments 159Command Query Separation 164Prefer Exceptions to Returning Error Codes 165DRY: Don't Repeat Yourself 169Side Effects 177Structured Programming 181This Is Too Much to Constantly Keep in Mind 183Conclusion 184Chapter 9: The Clean Method 185Make It Right 186Example 188Conclusion 210Chapter 10: One Thing 211Extract Method Refactoring 212What Are Large Functions Anyway? 217Conclusion 239Chapter 11: Be Polite 241The Newspaper Metaphor 243The Stepdown Rule: Once Again 245The Abstraction Roller Coaster 246This Is How We Write, but Not How We Want to Read 246Chapter 12: Objects and Data Structures 249What Is an Object? 250Data Abstraction 251Data/Object Antisymmetry 252The Law of Demeter 255Data Transfer Objects 258Switch Statements 260The OO/Procedural Trade-off 264But What About Performance? 265Conclusion 265Chapter 13: Clean Classes 267Classes and Modules versus Files 267What Should a Class Contain? 268Chapter 14: Testing Disciplines 289Discipline 1: Test-Driven Development (TDD) 291Discipline 2: Test && Commit || Revert (TCR) 292Discipline 3: Small Bundles 293Design 293Discipline 294Keeping Tests Clean 299Tests Enable the -ilities 300Chapter 15: Clean Tests 303Domain-Specific Testing Language 307F.I.R.S.T. 310Test Design 311Conclusion 311Chapter 16: Acceptance Testing 313The Acceptance Testing Discipline 314Conclusion 316Chapter 17: AIs, LLMs, and God Knows What 317Programming by Prompt 319Conclusion 328Part II: Design 329Chapter 18: Simple Design 331YAGNI 333Covered by Tests 333Maximize Expression 334Minimize Duplication 337Chapter 19: The SOLID Principles 341SRP: The Single Responsibility Principle 343OCP: The Open–Closed Principle 347LSP: The Liskov Substitution Principle 351ISP: The Interface Segregation Principle 354DIP: The Dependency Inversion Principle 356Chapter 20: Component Principles 363Components 364A Brief History of Components 364Component Cohesion 368Component Coupling 373Conclusion 387Chapter 21: Continuous Design 389Continuous Change 390Continuous Design 391Sailing on the Four Cs of Continuous Design 392When Else Do We Design? 420Chapter 22: Concurrency 423Why Concurrency? 424Concurrency Defense Principles 4272025 Update and Report from the Field 437Conclusion 442Part III: Architecture 443Chapter 23: The Two Values of Software 445Keeping Options Open 446Chapter 24: Independence 449Use Cases 450Operation 450Development 451Deployment 451Leaving Options Open 451Chapter 25: Architectural Boundaries 453What Lines Do You Draw, and When? 454Plug-in Architecture 456Case Study: FitNesse 457Conclusion 459Chapter 26: Clean Boundaries 461Third-Party IoT Framework: Lots o' Boundaries 462UI/Application Boundary 466Clean Boundaries 474Chapter 27: The Clean Architecture 475The Dependency Rule 476Conclusion 481Part IV: Craftmanship 483"A Great Number" 484Eight Decades 484The Oath 492Chapter 28: Harm 495No Harm to Society 496Harm to Function 497No Harm to Structure 499Soft 500Tests 501Chapter 29: No Defect in Behavior or Structure 503Making It Right 504Programmers Are Stakeholders 507Do Your Best 508Chapter 30: Repeatable Proof 511Dijkstra 511Structured Programming 514Functional Decomposition 516Test-Driven Development et al. 517Chapter 31: Small Cycles 519The History of Source Code Control 519Continuous Integration 524Branches versus Toggles 525Continuous Deployment 527Continuous Build 528Chapter 32: Relentless Improvement 529Test Coverage 529Mutation Testing 530Semantic Stability 530Cleaning 531Creations 531Chapter 33: Maintain High Productivity 533Viscosity 533Managing Distractions 535Time Management 538Chapter 34: Work as a Team 539Collaborative Programming 539Open/Virtual Office 540Chapter 35: Estimate Honestly and Fairly 543Lies 544Honesty, Accuracy, Precision 544Lessons from Me 545Accuracy and Precision 547Aggregation 548Honesty 549Pressure 550Chapter 36: Respect for Fellow Programmers 553Chapter 37: Never Stop Learning 555Afterword 557Appendix: The Clean Code Debate 561Introductions 562Method Length 563Method Length Summary 575Comments 576Comments Summary 590John's Rewrite of PrimeGenerator 591A Tale of Two Programmers 596Bob's Rewrite of PrimeGenerator2 599Test-Driven Development 603TDD Summary 612Closing Remarks 613Bibliography 615Index 619

Praise for the First Edition of Clean Code"Clean Code has changed the way I develop and maintain software in so many ways. It defines so well how code should be written, and I have not only learnt much from this book but have also put into practice many of its gems. I can honestly say that having gone on this journey, it is once again a pleasure to develop software and look at code that you are proud to have written."--Steve Roberts, head of IT"Reading Clean Code validated my inner sense of how software should be written, while also improving the quality of my work by teaching me things I didn't know. I'm grateful for this book and others by the same author as they remain fundamental prerequisites, even in the age of AI."--Milos Baic, developer and solution architect"[Clean Code] was the single most influential thing that I encountered in my career. Provided I was in a team that adhered to it, it took a lot of stress away as the code was suddenly more understandable and thus easier to maintain. To design something with testability in mind eliminated a lot of complexity in design and maintenance. Above all, it made programming feel cozy and fun again. The feeling gets stronger when you move from poor to a cleaner code base."--Žarko Stojanović, staff software engineer