Clean Code. Whew!
Posted by Uncle Bob on 04/08/2008
I’ve been working on this book for several years now. After a flurry of effort (you might have noticed I’ve been quiet lately) I’m very pleased to say that I’m done with the writing and am preparing the manuscript for production. See The Prentice Hall Listing
Table of Contents
Clean Code 1
There Will Be Code 1
Bad Code 2
The Total Cost of Owning a Mess. 3
Schools of Thought. 11
We are Authors. 12
The Boy Scout Rule 13
Prequel and Principles 14
Conclusion 14
Bibliography 15
Meaningful Names by Tim Ottinger 17
Introduction 17
Use Intention-revealing Names 17
Avoid Disinformation 19
Make Meaningful Distinctions 20
Use Pronounceable Names 21
Use Searchable Names 22
Avoid Encodings 23
Avoid Mental Mapping 24
Class Names 25
Method Names 25
Don't Be Cute 25
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
Functions 31
Small! 34
Do one thing. 35
One level of abstraction per function. 36
Switch Statements. 37
Use descriptive names. 39
Function Arguments. 39
Have no side-effects. 43
Command Query Separation 44
Prefer exceptions to returning error codes. 45
Don't Repeat Yourself. 47
Structured Programming 48
How do you write functions like this? 48
Conclusion 49
SetupTeardownIncluder 49
Bibliography 52
Comments 53
Comments do not make up for bad code. 55
Explain yourself in code. 55
Good Comments 55
Bad Comments 59
Example 71
Bibliography 74
Formatting 75
The Purpose of Formatting 76
Vertical Formatting 76
Horizontal Formatting 84
Team Rules 89
Uncle Bob's Formatting Rules. 90
Objects and Data Structures 93
Data Abstraction 93
Data/Object anti-symmetry. 95
The Law of Demeter 97
Data Transfer Objects 99
Conclusion 101
Bibliography 101
Error Handling by Michael Feathers 103
Use Exceptions Rather than Return Codes 103
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
Boundaries by James Grenning 113
Bibliography 119
Unit Tests 121
The Three Laws of TDD 122
Keeping Tests Clean 123
Clean Tests 124
One Assert per Test 129
F.I.R.S.T. 132
Conclusion 132
Bibliography 133
Classes 135
Class Organization 135
Classes should be Small! 136
Organizing for Change 146
Bibliography 150
Systems By Dean Wampler 151
How would you build a city? 151
Separate constructing a system from using it 152
Scaling Up 155
Java Proxies 158
Pure Java AOP Frameworks 160
AspectJ Aspects 163
Test-drive the system architecture 164
Optimize decision making 165
Use standards wisely, when they add demonstrable value 165
Systems need Domain-Specific Languages 166
Conclusion 166
Bibliography 167
Emergence By Jeff Langr 169
Getting Clean via Emergent Design 169
Simple Design Rule 1: Runs all the tests 170
Simple Design Rules 2-4: Refactoring 170
No Duplication 170
Expressive 173
Minimal Classes and Methods 174
Conclusion 174
Bibliography 174
Concurrency by Brett Schuchert 175
Why Concurrency? 176
Challenges 177
Concurrency Defense Principles 178
Know Your Library 180
Know Your Execution Models 181
Beware Dependencies between Syncrhonized Methods 182
Keep Synchronized Sections Small 183
Writing Correct Shut-Down Code is Hard 183
Testing Threaded Code 184
Conclusion 188
Bibliography 189
Successive Refinement 191
Args Implementation 192
Args: the rough draft. 198
String Arguments 212
Conclusion 246
JUnit Internals 249
Conclusion 262
Refactoring SerialDate 263
Conclusion 280
Bibliography 281
Smells and Heuristics 283
Comments 283
Environment 284
Functions 285
General 285
Java 304
Names 306
Tests 310
Conclusion 311
Bibliography 312
Concurrency II by Brett Schuchert 313
Client/Server Example 313
Possible Paths of Execution 317
Knowing Your Library 322
Dependencies between methods can break concurrent code 325
Increasing Throughput 329
Deadlock 331
Testing Multi-Threaded Code 335
Tool Support for Testing Thread-Based Code 337
Conclusion 338
Tutorial: Full Code Examples 339
org.jfree.date.SerialDate 345
Cross References of Heuristics 406
Comments
Paddy Healey about 1 hour later:
Congratulations getting this done Bob. I saw you give the Clean Code – Args talk at Agile 2006 and you were gathering feedback about whether there was a book in this subject. The result from the room seemed to be an overwhelming “yes!” and I’ve been eagerly awaiting the book ever since. The Table of Contents makes it look like this will be worth the wait. It will be on my shelf the day it comes out.
Philip Schwarz about 3 hours later:
Any idea of when it will hit the shelves in the UK? When will it be pre-orderable on Amazon UK? Thanks. An impatient reader. Your previous book, ‘Agile Software Development – Principles, Patterns, and Practices’ is, in my humble opinion, one of the best development books (there are Kent Beck’s books as well) I have ever come across. Pure quality. It is a ‘must read’.
Stephen Seymour about 7 hours later:
Thank you very much, Dr. Martin. I feel indebted to you for writing “Agile Software Development” because it truly helped further my understanding of software development. I suppose I did the work on my end by reading it and digesting it, but your book has had a ripple effect of helping my entire family by putting me in a position to do well in our industry.
Thank you, sincerely, once again. I will certainly buy and read your new book. It’s an investment only the foolish wouldn’t make.
Dave Hoover 1 day later:
Great to hear that this book is coming soon! I am excited to read it and share it with my team.
flipdoubt 1 day later:
Looking forward to it.
One question that has been nagging me lately: I believe I grok the benefit of the SRP, but if all your classes are responsible for just one thing, won’t your software do just one thing? I don’t mean for that to sound overly simplistic. I’m more interested in learning where the best place is to bring all these single responsibilities together to deliver real value to the user.
http://www.grayger.com/wp/ 6 days later:
I am looking forward to the book, especially chapter “error handling” and “concurrency”. Any sample chapter available?
Pete 10 days later:
Look forward to reading the book and more blog posts!
I have three other books from the Robert C Martin series but none by the man himself. They’re all quite brilliant in their own ways. Working Effectively With Legacy Code, Agile Java and FIT for Software Development. I expect the quality of Clean Code to be similar.
Have you got plans for a paperback edition of Agile Software Development?
TonyB 15 days later:
Looks good. I have a copy of Agile Principles, Practices and Patterns in C#, which is one of the most readable and clear software books I’ve ever read. In fact it’s the only one I’ve ever finished. I appreciate many of these concepts are cross-language, but will the examples in the new book be oriented towards C#, Java or what?
Aaron 24 days later:
Looking forward!
When exactly would this book be published?
mBria about 1 month later:
Congrats…this is awesome news, I’ve been waiting with baited breath. If you’re looking for reviewers, I’d love to have the opportunity. Cheers!
—MB
(bria526 at gmail)
rev about 1 month later:
still got my ‘test first’ bracelet. when can we get this from amazon?
Philip Johnson 5 months later:
Here’s my review:
Mike Finney 8 months later:
This is a fantastic book. As shared in my review of the Clean Code book, it’s a mind jarring, supportive, and thought provoking book!
Rolf 8 months later:
More people should understand how to write clean code. It will make all of our lifes a lot more pleasant. It’s on my christmas list :-)
Neil 8 months later:
I just bought this book and read it cover-to-cover. I have been looking for a book like this for Java since I read “Writing Solid Code” many years ago! Super-excellent book. Renforces the thinking I have been having for years reading crappy code. I have some comments/errata – Where can I send/post these?
waterproof digital about 1 year later:
Congrats…this is awesome news, I’ve been waiting with baited breath. If you’re looking for reviewers, I’d love to have the opportunity. Cheers!
David Mårtensson about 1 year later:
Hi.
I am reading the book right now and I found it very rewarding.
I have already started to use the principles despite not even being done with it.
But I have found what I consider a failed assumption on page 300.
FEET_PER_MILE is said to be such a well known constant not needing explanation.
Well, I live in Sweden where we use meter and kilometer, not feet and mile, I would never have guessed what 5280 stood for without explanation.
You should not make cultural assumptions like that as software development is a global business. :-)
But thanks for writing the book, it have made me a much better programmer so far in just over a week.
And seen some real improvement in the code I work with daily.
Daniel about 1 year later:
Hello, I put up an unofficial errata page for the book since there isn’t an official errata list:http://www.engineering.uiowa.edu/~wwalls/clean_code_errata/
Contributions welcome and will be attributed.
ClubPenguinCheats about 1 year later:
I saw you give the Clean Code – Args talk at Agile 2006 and you were gathering feedback about whether there was a book in this subject. The result from the room seemed to be an overwhelming “yes!” and I’ve been eagerly awaiting the book ever since. The Table of Contents makes it look like this will be worth the wait. It will be on my shelf the day it comes out