Quotes About Clarity

We want our code to be a quick skim, not an intense study.

What makes a clean test? Three things. Readability, readability, and readability.

Providing too much detail can be an invitation for micro-management.

The problem isn't the simplicity of the code but the implicity of the code (to coin a phrase): the degree to which the context is not explicit in the code itself.

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.

is not the language that makes programs appear simple. It is the programmer that make the language appear simple!

Professionals use their powers for good and write code that others can understand.

Cuteness in code often appears in the form of colloquialisms or slang. For example, don't use the name whack() to mean kill(). Don't tell little culture-dependent jokes like eatMyShorts() to mean abort(). Say what you mean. Mean what you say.

WHICH LINES DO YOU DRAW, AND WHEN DO YOU DRAW THEM? You draw lines between things that matter and things that don't. The GUI doesn't matter to the business rules, so there should be a line between them. The database doesn't matter to the GUI, so there should be a line between them. The database doesn't matter to the business rules, so there should be a line between them.

Resisting premature abstraction is as important as abstraction itself.

The hardest thing about choosing good names is that it requires good descriptive skills and a shared cultural background. This is a teaching issue rather than a technical, business, or management issue.

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.

A good architect maximizes the number of decisions not made.

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.

You know you are working on clean code when each routine turns out to be pretty much what you expected.

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.

The most important thing a good architecture can do to support behavior is to clarify and expose that behavior so that the intent of the system is visible at the architectural level.

The fact is that making messes is always slower than staying clean, no matter which time scale you are using.

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.

Whether you are designing systems or individual modules, never forget to use the simplest thing that can possibly work.

Ward's principle: "You know you are working on clean code when each routine turns out to be pretty much what you expected.

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

So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.

A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.