Book Quotes - Clean Code: A Handbook of Agile Software Craftsmanship

The second stop in my "Book Quotes" series is, of course, Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin.

Here are the quotes that stuck with me and that I try to enforce in my day-to-day work life:

• We should never ignore any part of code. The parts we ignore are where the bugs will hide.
• You should name a variable using the same care with which you name a first-born child.
• The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.
• People are also afraid of renaming things for fear that some other developers will object. We do not share that fear and find that we are actually grateful when names change (for the better). Most of the time we don't really memorize the names of classes and methods. We use modern tools to deal with details like that so we can focus on whether the code reads like paragraphs and sentences, or at least like tables and data structures (a sentence isn't always the best way to display data). You will probably end up surprising someone when you rename just like you might with any other code improvement. Don't let it stop you in your tracks.
• Functions should do only one thing. They should do it well. They should only do it.
• Error Handling Is One Thing. Functions should do one thing. Error handling is one thing. Thus, a function that handles errors should do nothing else. This implies that if the keyword try exists in a function, it should be the very first word in the function and that there should be nothing after the catch/finally blocks.
• One level of abstraction per function.
• Anything that forces you to check the function signature is equivalent to a double-take. It's a cognitive break and should be avoided.
• The proper use of comments is to compensate for our failure to express ourselves in code.
• The older a comment is, and the farther it is from the code it describes, the more likely it is to be just plain wrong.
• The coding style and readability set precedents that continue to affect maintainability and extensibility long after the original code has been changed beyond recognition. Your style and discipline survive, even though your code does not.
• If one function calls another, they should be vertically close and the caller should be above the callee. From high level to low level.
• The Three Laws of TDD
  By now everyone knows that TDD asks us to write unit tests first, before we write production code. But that rule is just the tip of the iceberg. Consider the following three laws.
  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.
• The name of a class should describe what responsibilities it fulfills. The more ambiguous the name, the more responsibilities it likely has.
• We should be able to write a brief description of the class in about 25 words without using the words "if" "and" "or" "but".
• The separation of concerns is one of the oldest and most important design techniques in our craft.
• A powerful mechanism for separating construction from use is dependency injection. In the context of dependency management, an object should not take responsibility for instantiating dependencies itself.
• Software systems are unique compared to physical systems. Their architectures can grow incrementally if we maintain the proper separation of concerns.
• It is best to postpone decisions until the last possible moment. It let's us make informed choices with the best possible information.
• Whenever you are designing systems or individual modules, never forget to use the simplest thing that can possibly work.
• According to Kent Beck, a design is simple if it follows these rules (the rules are given in order of importance):
  Runs all the tests.
  Contains no duplication.
  Expresses the intent of the programmer.
  Minimizes the number of classes and methods.