Clean Code: A Handbook of Agile Software Craftsmanship / Edition 1

by Robert Martin

Overview

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.

Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.

What kind of work will you be doing? You’ll be reading code—lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft.

Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.

Readers will come away from this book understanding

• How to tell the difference between good and bad code
• How to write good code and how to transform bad code into good code
• How to create good names, good functions, good objects, and good classes
• How to format code for maximum readability
• How to implement complete error handling without obscuring code logic
• How to unit test and practice test-driven development

This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.

Product Details

ISBN-13:	9780132350884
Publisher:	Pearson Education
Publication date:	08/01/2008
Series:	Robert C. Martin Series
Edition description:	New Edition
Pages:	464
Sales rank:	37,857
Product dimensions:	6.90(w) x 9.20(h) x 0.90(d)

About the Author

Robert C. “Uncle Bob” Martin has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor, Inc., a team of experienced consultants who mentor their clients worldwide in the fields of C++, Java, C#, Ruby, OO, Design Patterns, UML, Agile Methodologies, and eXtreme programming.

Table of Contents

Foreword xix
Introduction xxv
On the Cover xxix

Chapter 1: Clean Code 1
There Will Be Code 2
Bad Code 3
The Total Cost of Owning a Mess 4
Schools of Thought 12
We Are Authors 13
The Boy Scout Rule 14
Prequel and Principles 15
Conclusion 15
Bibliography 15

Chapter 2: Meaningful Names 17
Introduction 17
Use Intention-Revealing Names 18
Avoid Disinformation 19
Make Meaningful Distinctions 20
Use Pronounceable Names 21
Use Searchable Names 22
Avoid Encodings 23
Avoid Mental Mapping 25
Class Names 25
Method Names 25
Don’t Be Cute 26
Pick One Word per Concept 26
Don’t Pun 26
Use Solution Domain Names 27
Use Problem Domain Names 27
Add Meaningful Context 27
Don’t Add Gratuitous Context 29
Final Words 30

Chapter 3: Functions 31
Small! 34
Do One Thing 35
One Level of Abstraction per Function 36
Switch Statements 37
Use Descriptive Names 39
Function Arguments 40
Have No Side Effects 44
Command Query Separation 45
Prefer Exceptions to Returning Error Codes 46
Don’t Repeat Yourself 48
Structured Programming 48
How Do You Write Functions Like This? 49
Conclusion 49
SetupTeardownIncluder 50
Bibliography 52

Chapter 4: Comments 53
Comments Do Not Make Up for Bad Code 55
Explain Yourself in Code 55
Good Comments 55
Bad Comments 59
Bibliography 74

Chapter 5: Formatting 75
The Purpose of Formatting 76
Vertical Formatting 76
Horizontal Formatting 85
Team Rules 90
Uncle Bob’s Formatting Rules 90
Chapter 6: Objects and Data Structures 93
Data Abstraction 93
Data/Object Anti-Symmetry 95
The Law of Demeter 97
Data Transfer Objects 100
Conclusion 101
Bibliography 101

Chapter 7: Error Handling 103
Use Exceptions Rather Than Return Codes 104
Write Your Try-Catch-Finally Statement First 105
Use Unchecked Exceptions 106
Provide Context with Exceptions 107
Define Exception Classes in Terms of a Caller’s Needs 107
Define the Normal Flow 109
Don’t Return Null 110
Don’t Pass Null 111
Conclusion 112
Bibliography 112

Chapter 8: Boundaries 113
Using Third-Party Code 114
Exploring and Learning Boundaries 116
Learning log4j 116
Learning Tests Are Better Than Free 118
Using Code That Does Not Yet Exist 118
Clean Boundaries 120
Bibliography 120

Chapter 9: Unit Tests 121
The Three Laws of TDD 122
Keeping Tests Clean 123
Clean Tests 124
One Assert per Test 130
F.I.R.S.T. 132
Conclusion 133
Bibliography 133

Chapter 10: Classes 135
Class Organization 136
Classes Should Be Small! 136
Organizing for Change 147
Bibliography 151

Chapter 11: Systems 153
How Would You Build a City? 154
Separate Constructing a System from Using It 154
Scaling Up 157
Java Proxies 161
Pure Java AOP Frameworks 163
AspectJ Aspects 166
Test Drive the System Architecture 166
Optimize Decision Making 167
Use Standards Wisely, When They Add Demonstrable Value 168
Systems Need Domain-Specific Languages 168
Conclusion 169
Bibliography 169

Chapter 12: Emergence 171
Getting Clean via Emergent Design 171
Simple Design Rule 1: Runs All the Tests 172
Simple Design Rules 2–4: Refactoring 172
No Duplication 173
Expressive 175
Minimal Classes and Methods 176
Conclusion 176
Bibliography 176

Chapter 13: Concurrency 177
Why Concurrency? 178
Challenges 180
Concurrency Defense Principles 180
Know Your Library 182
Know Your Execution Models 183
Beware Dependencies Between Synchronized Methods 185
Keep Synchronized Sections Small 185
Writing Correct Shut-Down Code Is Hard 186
Testing Threaded Code 186
Conclusion 190
Bibliography 191

Chapter 14: Successive Refinement 193
Args Implementation 194
Args: The Rough Draft 201
String Arguments 214
Conclusion 250

Chapter 15: JUnit Internals 251
The JUnit Framework 252
Conclusion 265

Chapter 16: Refactoring SerialDate 267
First, Make It Work 268
Then Make It Right 270
Conclusion 284
Bibliography 284

Chapter 17: Smells and Heuristics 285
Comments 286
Environment 287
Functions 288
General 288
Java 307
Names 309
Tests 313
Conclusion 314
Bibliography 315

Appendix A: Concurrency II 317
Client/Server Example 317
Possible Paths of Execution 321
Knowing Your Library 326
Dependencies Between Methods Can Break Concurrent Code 329
Increasing Throughput 333
Deadlock 335
Testing Multithreaded Code 339
Tool Support for Testing Thread-Based Code 342
Conclusion 342
Tutorial: Full Code Examples 343

Appendix B: org.jfree.date.SerialDate 349

Appendix C: Cross References of Heuristics 409

Epilogue 411
Index 413

Preface

Which door represents your code? Which door represents your team or your company? Why are we in that room? Is this just a normal code review or have we found a stream of horrible problems shortly after going live? Are we debugging in a panic, poring over code that we thought worked? Are customers leaving in droves and managers breathing down our necks? How can we make sure we wind up behind the right door when the going gets tough? The answer is: craftsmanship.

There are two parts to learning craftsmanship: knowledge and work. You must gain the knowledge of principles, patterns, practices, and heuristics that a craftsman knows, and you must also grind that knowledge into your fingers, eyes, and gut by working hard and practicing.

I can teach you the physics of riding a bicycle. Indeed, the classical mathematics is relatively straightforward. Gravity, friction, angular momentum, center of mass, and so forth, can be demonstrated with less than a page full of equations. Given those formulae I could prove to you that bicycle riding is practical and give you all the knowledge you needed to make it work. And you'd still fall down the first time you climbed on that bike.

Coding is no different. We could write down all the 'feel good' principles of clean code and then trust you to do the work (in other words, let you fall down when you get on the bike), but then what kind of teachers would that make us, and what kind of student would that make you?

No. That's not the way this book is going to work.

Learning to write clean code is hard work. It requires more than just the knowledge of principles and patterns. You must sweat over it. You must practice it yourself, and watch yourself fail. You must watch others practice it and fail. You must see them stumble and retrace their steps. You must see them agonize over decisions and see the price they pay for making those decisions the wrong way.

Be prepared to work hard while reading this book. This is not a 'feel good' book that you can read on an airplane and finish before you land. This book will make you work, and work hard. What kind of work will you be doing? You'll be reading code—lots of code. And you will be challenged to think about what's right about that code and what's wrong with it. You'll be asked to follow along as we take modules apart and put them back together again. This will take time and effort; but we think it will be worth it.

We have divided this book into three parts. The first several chapters describe the principles, patterns, and practices of writing clean code. There is quite a bit of code in these chapters, and they will be challenging to read. They'll prepare you for the second section to come. If you put the book down after reading the first section, good luck to you!

The second part of the book is the harder work. It consists of several case studies of ever-increasing complexity. Each case study is an exercise in cleaning up some code—of transforming code that has some problems into code that has fewer problems. The detail in this section is intense. You will have to flip back and forth between the narrative and the code listings. You will have to analyze and understand the code we are working with and walk through our reasoning for making each change we make. Set aside some time because this should take you days.

The third part of this book is the payoff. It is a single chapter containing a list of heuristics and smells gathered while creating the case studies. As we walked through and cleaned up the code in the case studies, we documented every reason for our actions as a heuristic or smell. We tried to understand our own reactions to the code we were reading and changing, and worked hard to capture why we felt what we felt and did what we did. The result is a knowledge base that desribes the way we think when we write, read, and clean code.

This knowledge base is of limited value if you don't do the work of carefully reading through the case studies in the second part of this book. In those case studies we have carefully annotated each change we made with forward references to the heuristics. These forward references appear in square brackets like this: H22. This lets you see the context in which those heuristics were applied and written! It is not the heuristics themselves that are so valuable, it is the relationship between those heuristics and the discrete decisions we made while cleaning up the code in the case studies.

To further help you with those relationships, we have placed a cross-reference at the end of the book that shows the page number for every forward reference. You can use it to look up each place where a certain heuristic was applied.

If you read the first and third sections and skip over the case studies, then you will have read yet another 'feel good' book about writing good software. But if you take the time to work through the case studies, following every tiny step, every minute decision—if you put yourself in our place, and force yourself to think along the same paths that we thought, then you will gain a much richer understanding of those principles, patterns, practices, and heuristics. They won't be 'feel good' knowledge any more. They'll have been ground into your gut, fingers, and heart. They'll have become part of you in the same way that a bicycle becomes an extension of your will when you have mastered how to ride it.