Quotes About Code

The most efficient and effective way to review code is to collaborate in writing it.

The tests fit the production code like an antibody fits an antigen.

Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.

refactored)    /**

The complement is also true: Procedural code makes it hard to add new data structures because all the functions must change. OO code makes it hard to add new functions because all the classes must change.

The Stable Abstractions Principle (SAP) sets up a relationship between stability and abstractness. On the one hand, it says that a stable component should also be abstract so that its stability does not prevent it from being extended. On the other hand, it says that an unstable component should be concrete since its instability allows the concrete code within it to be easily changed.

In an ideal system, we incorporate new features by extending the system, not by making modifications to existing code.

OCP: The Open-Closed Principle Bertrand Meyer made this principle famous in the 1980s. The gist is that for software systems to be easy to change, they must be designed to allow the behavior of those systems to be changed by adding new code, rather than changing existing code.

software artifact should be open for extension but closed for modification.

DIP: The Dependency Inversion Principle The code that implements high-level policy should not depend on the code that implements low-level details. Rather, details should depend on policies.

One of the more common motivations for writing comments is bad code.

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.

Am I suggesting 100% test coverage? No, I'm not suggesting it. I'm demanding it. Every single line of code that you write should be tested. Period. Isn't that unrealistic? Of course not. You only write code because you expect it to get executed. If you expect it to get executed, you ought to know that it works. The only way to know this is to test it.

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.

Duplication may be the root of all evil in software.

The moral of the story is simple: Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.

The business rules should be the most independent and reusable code in the system.

Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.

The first value of software is its behavior. Programmers are hired to make machines behave in a way that makes or saves money for the stakeholders. We do this by helping the stakeholders develop a functional specification, or requirements document. Then we write the code that causes the stakeholder's machines to satisfy those requirements.

The Three Laws of TDD You are not allowed to write any production code until you have first written a failing unit test. You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing. You are not allowed to write more production code that is sufficient to pass the currently failing unit test.

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.

structured programming, object-orient programming, and functional programming.

Don't comment bad code—rewrite it." —Brian W. Kernighan and P. J. Plaugher1

Dependent Functions. If one function calls another, they should be vertically close, and the caller should be above the callee, if at all possible.