Forward

You should name a variable using the same care with which you name a first-born child (xxi).

Quality is the result of a million selfless acts of care--not just of any great method that descends from the heavens. That these acts are simple doesn't mean that they are simplistic, and it hardly means that they are easy. They are nonetheless the fabric of greatness and, more so, of beauty, in any endeavor. To ignore them is not yet to be fully human (xxii).

Chapter 2: Meaningful Names

Clarity is king (25).

Our goal, as authors, is to make our code as easy as possible to understand. We want our code to be a quick skim, not an intense study. We want to use the popular paperback model whereby the author is responsible for making himself clear and not the academic model where it is the scholar's job to dig the meaning out of the paper (27).

Chapter 3: Functions

Functions are the first line of organization in any program (31).

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that (34).

FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL. THEY SHOULD DO IT ONLY (35).

So, 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 (36).

Master programmers think of systems as stories to be told rather than programs to be written (49).

Chapter 4: Comments

The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration (54).

The older a comment is, and the farther away it is from the code it describes, the more likely it is to be just plain wrong. The reason is simple. Programmers can't realistically maintain them (54).

Truth can only be found in one place: the code (54).

It takes only a few seconds of thought to explain most of your intent in code. In many cases it's simply a matter of creating a function that says the same thing as the comment you want to write (55).

Plopping in a comment just because you feel you should or because the process requires it, is a hack (59).

Any comment that forces you to look in another module for the meaning of that comment has failed to communicate to you and is not worth the bits it consumes (60).

Others who see that commented-out code won't have the courage to delete it (68).

Chapter 5 - Formatting

Each line represents an expression or a clause, and each group of lines represents a complete thought. Those thoughts should be separated from each other with blank lines (78).

Have you ever hunted up the chain of inheritance for the definition of a variable or function? This is frustrating because you are trying to understand what the system does, but you are spending your time and mental energy on trying to locate and remember where the peices are. Concepts that are closely related should be kept vertically close to each other. Clearly this rule doesn't work for concepts that belong in separate files. But then closely related concepts should not be separated into different files unless you have a very good reason.  Indeed, this is one of the reasons that protected variables should be avoided (80).

All quotes from Clean Code: A Handbook of Agile Software Craftsmanship by Robert C Martin.