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... read more
“Passing a Boolean into a function is a truly terrible practice”
“We don't usually expect information to be going out through the arguments”
“When we read a function, we are used to the idea of information going in to the function through arguments and out through the return value”
“Clear and expressive code with few comments is far superior to cluttered and complex code with lots of comments”
“Rather than spend your time writing the comments that explain the mess you've made, spend it cleaning that mess”
“The first rule of classes is that they should be small”
“And you will be challenged to think about what's right about that code and what's wrong with it”
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.Highlighted by 151 Kindle customers
FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL. THEY SHOULD DO IT ONLY.Highlighted by 149 Kindle customers
Functions should either do something or answer something, but not both.Highlighted by 142 Kindle customers
Objects hide their data behind abstractions and expose functions that operate on that data. Data structure expose their data and have no meaningful functions.Highlighted by 118 Kindle customers
In general output arguments should be avoided. If your function must change the state of something, have it change the state of its owning object.Highlighted by 107 Kindle customers
The Single Responsibility Principle (SRP)2 states that a class or module should have one, and only one, reason to change.Highlighted by 96 Kindle customers
another way to know that a function is doing more than “one thing” is if you can extract another function from it with a name that is not merely a restatement of its implementation [G34].Highlighted by 94 Kindle customers
The length of a name should correspond to the size of its scope [N5].Highlighted by 83 Kindle customers
Of course, in those days we didn’t know LeBlanc’s law: Later equals never.Highlighted by 79 Kindle customers
Functions that do one thing cannot be reasonably divided into sections.Highlighted by 77 Kindle customers
Foreward
Introduction
On the Cover
Chapter 1: Clean Code
Chapter 2: Meaningful Names
Chapter 3: Functions
Chapter 4: Comments
Chapter 5: Formatting
Chapter 6: Objects and Data Structures
Chapter 7: Error Handling
Chapter 8: Boundaries
Chapter 9: Unit Tests
Chapter 10: Classes
Chapter 11: Systems
Chapter 12: Emergence
Chapter 13: Concurrency
Chapter 14: Successive Refinement
Chapter 15: JUnit Internals
Chapter 16: Refactoring SerialDate
Chapter 17: Smells and Heuristics
Appendix A: Concurrency II
Appendix B: org.jfree.date.SerialDate
Appendix C: Cross References of Heuristics
Epilogue
Index
We’re hiding the characters, settings, errata, movie connections, books influenced by this book, books that cite this book and books cited by this book sections. If you would like to add content to them, you must first make them visible.