Clean Code Quotes

“The only way to make the deadline—the only way to go fast—is to keep the code as clean as possible at all times.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“As they added more and more features, the code got worse and worse until they simply could not manage it any longer. It was the bad code that brought the company down.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“The folks who think that code will one day disappear are like mathematicians who hope one day to discover a mathematics that does not have to be formal. They are hoping that one day we will discover a way to create machines that can do what we want rather than what we say. These machines will have to be able to understand us so well that they can translate vaguely specified needs into perfectly executing programs that precisely meet those needs. This will never happen.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“How can we make sure we wind up behind the right door when the going gets tough? The answer is: craftsmanship.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Master programmers think of systems as stories to be told rather than programs to be written.

Chapter 3: Functions • Conclusion
p. 49”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“So the question is: Do you want your tools organized into toolboxes with many small drawers each containing well-defined and well-labeled components? Or do you want a few drawers that you just toss everything into?”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“If you throw a checked exception from a method in your code and the catch is three levels above, you must declare that exception in the signature of each method between you and the catch. This means that a change at a low level of the software can force signature changes on many higher levels.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“A stitch in time saves nine. The early bird catches the worm. Don’t put off until tomorrow what you can do”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“What attributes can we give our functions that will allow a casual reader to intuit the kind of program they live inside?”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Run with More Threads Than Processors Things happen when the system switches between tasks. To encourage task swapping, run with more threads than processors or cores. The more frequently your tasks swap, the more likely you’ll encounter code that is missing a critical section or causes deadlock.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“between”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“In Scrum, we make everything visible. We air our dirty laundry. We are honest about the state of our code because code is never perfect. We become more fully human, more worthy of the divine, and closer to that greatness in the details.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, Prentice Hall

“Duplication may be the root of all evil in software. Many principles and practices have been created for the purpose of controlling or eliminating it. Consider, for example, that all of Codd’s database normal forms serve to eliminate duplication in data. Consider also how object-oriented programming serves to concentrate code into base classes that would otherwise be redundant. Structured programming, Aspect Oriented Programming, Component Oriented Programming, are all, in part, strategies for eliminating duplication. It would appear that since the invention of the subroutine, innovations in software development have been an ongoing attempt to eliminate duplication from our source code.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“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.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Do we really need the constants FEET_PER_MILE,”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Os padrôes facilitam a reutilização de ideias e compomentes, recrutam pessoas com experiência considerável, encapsulam boas ideis e conectam os compomentes. Entretanto, o processo de criação de padôes pode, ás vezes, ser muito longo para que o mercado fique á espera deles, e alguns padrôes acabam se desviando das necessidades reais das pessoas a quem eles pretendem servir.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Code at the boundaries needs clear separation and tests that define expectations. We should avoid letting too much of our code know about the third-party particulars. It’s better to depend on something you control than on something you don’t control, lest it end up controlling you.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“We do not want to expose the details of our data. Rather we want to express our data in abstract terms. This is not merely accomplished by using interfaces and/or getters and setters. Serious thought needs to be put into the best way to represent the data that an object contains. The worst option is to blithely add getters and setters.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Don’t hide side effects with a name. Don’t use a simple verb to describe a function that does more than just that simple action.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Il campo @author di un Javadoc ci dice chi siamo. Siamo gli autori. E una caratteristica degli autori è che hanno dei lettori. In effetti, è responsabilità degli autori riuscire a comunicare bene coi loro lettori. La prossima volta che scriverete una riga di codice, ricordatevi che voi ne siete gli autori, e che scrivete a dei lettori che vi giudicheranno per quello che avrete scritto.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Refactoring is a lot like solving a Rubik’s cube. There are lots of little steps required to achieve a large goal. Each step enables the next.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Standards make it easier to reuse ideas and components, recruit people with relevant experience, encapsulate good ideas, and wire components together. However, the process of creating standards can sometimes take too long for industry to wait, and some standards lose touch with the real needs of the adopters they are intended to serve.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“God is in the details, said the architect Ludwig mies van der Rohe.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“One of the best ways to ruin a program is to make massive changes to its structure in the name of improvement. Some programs never recover from such “improvements.” The problem is that it’s very hard to get the program working the same way it worked before the “improvement.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“To write clean code, you must first write dirty code and then clean it.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Returning null from methods is bad, but passing null into methods is worse.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Encapsulation is broken because all functions in the path of a throw must know about details of that low-level exception. Given that the purpose of exceptions is to allow you to handle errors at a distance, it is a shame that checked exceptions break encapsulation in this way.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“If your function must change the state of something, have it change the state of its owning object.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Why does good code rot so quickly into bad code? We have lots of explanations for it. We complain that the requirements changed in ways that thwart the original design. We bemoan the schedules that were too tight to do things right. We blather about stupid managers and intolerant customers and useless marketing types and telephone sanitizers. But the fault, dear Dilbert, is not in our stars, but in ourselves. We are unprofessional.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

“Were you trying to go fast? Were you in a rush? Probably so. Perhaps you felt that you didn’t have time to do a good job; that your boss would be angry with you if you took the time to clean up your code. Perhaps you were just tired of working on this program and wanted it to be over. Or maybe you looked at the backlog of other stuff that you had promised to get done and realized that you needed to slam this module together so you could move on to the next. We’ve all done it. We’ve all looked at the mess we’ve just made and then have chosen to leave it for another day. We’ve all felt the relief of seeing our messy program work and deciding that a working mess is better than nothing. We’ve all said we’d go back and clean it up later. Of course, in those days we didn’t know LeBlanc’s law: Later equals never.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship