Clean Code Quotes

“A system that is comprehensively tested and passes all of its tests all of the time is a testable system. That’s an obvious statement, but an important one. Systems that aren’t testable aren’t verifiable. Arguably, a system that cannot be verified should never be deployed.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“It is unit tests that keep our code flexible, maintainable, and reusable. The reason is simple. If you have tests, you do not fear making changes to the code! Without tests every change is a possible bug.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“If names are too clever, they will be memorable only to people who share the author’s sense of humor, and only as long as these people remember the joke. Will they know what the function named HolyHandGrenade is supposed to do? Sure, it’s cute, but maybe in this case DeleteItems might be a better name. Choose clarity over entertainment value.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Over the span of a year or two, teams that were moving very fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two or three other parts of the code.
As productivity decreases, management does the only thing they can; they add more staff to the project to increase productivity. But that new staff is not versed in the design of the system. Furthermore, they, and everyone else on the team, are under horrific pressure to increase productivity. So they all make more and more messes, driving productivity further toward zero.
Eventually the team rebels. They inform management that they cannot continue to develop in this odious code base. Management does not want to expend resources on a whole new redesign of the project, but they cannot deny that productivity is terrible. Eventually, they bend to the demands of the developers and authorize the grand redesign in the sky.
A new tiger team is selected. Everyone wants to be on this team because it’s a green-field project. They get to start over and create something wonderful. But only the best and brightest are chosen for the tiger team. Everyone else must continue to maintain the current system.
Now the two teams are in a race. The tiger team must build a new system that does everything that the old system does. Management will not replace the old system until the new system can do everything that the old system does.
This race can go on for a very long time. I’ve seen it take 10 years. And by the time it’s done, the original members of the tiger team are long gone, and the current members are demanding that the new system be redesigned because it’s such a mess.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification—and then shouldn’t be used anyway.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“When people look under the hood, we want them to be impressed with the neatness, consistency, and attention to detail that they perceive. We want them to be struck by the orderliness. We want their eyebrows to rise as they scroll through the modules. We want them to perceive that professionals have been at work. If instead they see a scrambled mass of code that looks like it was written by a bevy of drunken sailors, then they are likely to conclude that the same inattention to detail pervades every other aspect of the project.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Yet attentiveness to detail is an even more critical foundation of professionalism than is any grand vision. First, it is through practice in the small that professionals gain proficiency and trust for practice in the large. Second, the smallest bit of sloppy construction, of the door that does not close tightly or the slightly crooked tile on the floor, or even the messy desk, completely dispels the charm of the larger whole. That is what clean code is about.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Flag arguments are ugly. Passing a boolean into a function is a truly terrible practice.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“We want our code to be a quick skim, not an intense study.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“abstraction is evil. Code is anti-evil, and clean code is perhaps divine.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“In about 1951, a quality approach called Total Productive Maintenance (TPM) came on the Japanese scene. Its focus is on maintenance rather than on production. One of the major pillars of TPM is the set of so-called 5S principles. 5S is a set of disciplines—and here I use the term “discipline” instructively. These 5S principles are in fact at the foundations of Lean—another buzzword on the Western scene, and an increasingly prominent buzzword in software circles. These principles are not an option. As Uncle Bob relates in his front matter, good software practice requires such discipline: focus, presence of mind, and thinking. It is not always just about doing, about pushing the factory equipment to produce at the optimal velocity. The 5S philosophy comprises these concepts: • Seiri, or organization (think “sort” in English). Knowing where things are—using approaches such as suitable naming—is crucial. You think naming identifiers isn’t important? Read on in the following chapters. • Seiton, or tidiness (think “systematize” in English). There is an old American saying: A place for everything, and everything in its place. A piece of code should be where you expect to find it—and, if not, you should re-factor to get it there. • Seiso, or cleaning (think “shine” in English): Keep the workplace free of hanging wires, grease, scraps, and waste. What do the authors here say about littering your code with comments and commented-out code lines that capture history or wishes for the future? Get rid of them. • Seiketsu, or standardization: The group agrees about how to keep the workplace clean. Do you think this book says anything about having a consistent coding style and set of practices within the group? Where do those standards come from? Read on. • Shutsuke, or discipline (self-discipline). This means having the discipline to follow the practices and to frequently reflect on one’s work and be willing to change.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“No matter how elegant it is, no matter how readable and accessible, if it hath not tests, it be unclean. Dave”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“If you let the tests rot, then your code will rot too. Keep your tests clean.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“What this team did not realize was that having dirty tests is equivalent to, if not worse than, having no tests.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“the ratio of time spent reading vs. writing is well over 10:1.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Clean code is focused. Each function, each class, each module exposes a single-minded attitude that remains entirely undistracted, and unpolluted, by the surrounding details.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many
ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be
literate since depending on the language, not all necessary information can be expressed clearly in code alone.

-Dave Thomas, founder
of OTI, godfather of the
Eclipse strategy”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“If the discipline of requirements specification has taught us anything, it is that well-specified requirements are as formal as code and can act as executable tests of that code!”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Building a project should be a single trivial operation.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don’t have time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a development project than bad code.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“The majority of the cost of a software project is in long-term maintenance. In order to minimize the potential for defects as we introduce change, it’s critical for us to be able to understand what a system does. As systems become more complex, they take more and more time for a developer to understand, and there is an ever greater opportunity for a misunderstanding. Therefore, code should clearly express the intent of its author. The clearer the author can make the code, the less time others will have to spend understanding it. This will reduce defects and shrink the cost of maintenance.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“It is a myth that we can get systems “right the first time.” Instead, we should implement only today’s stories, then refactor and expand the system to implement new stories tomorrow. This is the essence of iterative and incremental agility. Test-driven development, refactoring, and the clean code they produce make this work at the code level.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“What makes a clean test? Three things. Readability, readability, and readability.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Good software designs accommodate change without huge investments and rework. When we use code that is out of our control, special care must be taken to protect our investment and make sure future change is not too costly.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“In fact, wrapping third-party APIs is a best practice. When you wrap a third-party API, you minimize your dependencies upon it:”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Error handling is important, but if it obscures logic, it’s wrong.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“These comments are so noisy that we learn to ignore them. As we read through code, our eyes simply skip over them. Eventually the comments begin to lie as the code around them changes.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Because this ratio is so high, we want the reading of code to be easy, even if it makes the writing harder. Of course there’s no way to write code without reading it, so making it easy to read actually makes it easier to write.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Back in my days working in the Bell Labs Software Production Research organization (Production, indeed!) we had some back-of-the-envelope findings that suggested that consistent indentation style was one of the most statistically significant indicators of low bug density.”
― Martin Robert C., Clean Code: A Handbook of Agile Software Craftsmanship