Monnef > Monnef's Quotes

“Truth can only be found in one place: the code.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“It is not enough for code to work.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“You should name a variable using the same care with which you name a first-born child.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Redundant comments are just places to collect lies and misinformation.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“It is not the language that makes programs appear simple. It is the programmer that make the language appear simple!”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Don’t Use a Comment When You Can Use a Function or a Variable”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.
- Grady Booch author of Object
Oriented Analysis and Design with
Applications”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Whatever else a TODO might be, it is not an excuse to leave bad code in the system.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Duplication is the primary enemy of a well-designed system. It represents additional work, additional risk, and additional unnecessary complexity.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“First Law You may not write production code until you have written a failing unit test. Second Law You may not write more of a unit test than is sufficient to fail, and not compiling is failing. Third Law You may not write more production code than is sufficient to pass the currently failing test.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“A long descriptive name is better than a long descriptive comment.”
― 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

“I like my code to be elegant and efficient. The logic should be straightforward to make it hard
for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance
close to optimal so as not to tempt
people to make the code messy with unprincipled optimizations. Clean code does one thing well.

-Bjarne Stroustrup, inventor of C++
and author of The C++ Programming
Language”
― 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

“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

“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

“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

“You know you are working on clean code when each routine turns out to be pretty much what you expected.” Half”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“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

“Without tests every change is a possible bug. No”
― 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

“Indeed, many of the recommendations in this book are controversial. You will probably not agree with all of them.”
― 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

“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

“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

“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

“We want our code to be a quick skim, not an intense study.”
― 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