Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)
Rate it:
Open Preview
14%
Flag icon
In Listing 3-7 we had no choice because the callers were already passing that flag in, and I wanted to limit the scope of refactoring to the function and below. Still, the method call render(true) is just plain confusing to a poor reader. Mousing over the call and seeing render(boolean isSuite) helps a little, but not that much. We should have split the function into two: renderForSuite() and renderForSingleTest().
20%
Flag icon
Don’t Use a Comment When You Can Use a Function or a Variable
21%
Flag icon
Few practices are as odious as commenting-out code. Don’t do this!
24%
Flag icon
Dependent Functions. If one function calls another, they should be vertically close, and the caller should be above the callee, if at all possible. This gives the program a natural flow.
26%
Flag icon
Objects hide their data behind abstractions and expose functions that operate on that data. Data structure expose their data and have no meaningful functions.
27%
Flag icon
There is a well-known heuristic called the Law of Demeter2 that says a module should not know about the innards of the objects it manipulates.
28%
Flag icon
Objects expose behavior and hide data. This makes it easy to add new kinds of objects without changing existing behaviors. It also makes it hard to add new behaviors to existing objects. Data structures expose data and have no significant behavior. This makes it easy to add new behaviors to existing data structures but makes it hard to add new data structures to existing functions.
29%
Flag icon
when we define exception classes in an application, our most important concern should be how they are caught.
30%
Flag icon
This is called the SPECIAL CASE PATTERN [Fowler]. You create a class or configure an object so that it handles a special case for you.
30%
Flag icon
When we return null, we are essentially creating work for ourselves and foisting problems upon our callers. All it takes is one missing null check to send an application spinning out of control.
31%
Flag icon
Instead of experimenting and trying out the new stuff in our production code, we could write some tests to explore our understanding of the third-party code. Jim Newkirk calls such tests learning tests.1
32%
Flag icon
The learning tests end up costing nothing. We had to learn the API anyway, and writing those tests was an easy and isolated way to get that knowledge. The learning tests were precise experiments that helped increase our understanding.
32%
Flag icon
Without these boundary tests to ease the migration, we might be tempted to stay with the old version longer than we should.
32%
Flag icon
First Law You may not write production code until you have written a failing unit test.
33%
Flag icon
If you don’t keep your tests clean, you will lose them. And without them, you lose the very thing that keeps your production code flexible. Yes, you read that correctly. It is unit tests that keep our code flexible, maintainable, and reusable.
34%
Flag icon
One Assert per Test There is a school of thought4 that says that every test function in a JUnit test should have one and only one assert statement.
35%
Flag icon
Single Concept per Test Perhaps a better rule is that we want to test a single concept in each test function.
36%
Flag icon
We should also be able to write a brief description of the class in about 25 words, without using the words “if,” “and,” “or,” or “but.” How would we describe the
36%
Flag icon
The Single Responsibility Principle The Single Responsibility Principle (SRP)2 states that a class or module should have one, and only one, reason to change. This
36%
Flag icon
SRP is one of the more important concept in OO design. It’s also one of the simpler concepts to understand and adhere to. Yet oddly, SRP is often the most abused class design principle.
39%
Flag icon
It supports the SRP. It also supports another key OO class design principle known as the Open-Closed Principle, or OCP:4 Classes should be open for extension but closed for modification.
39%
Flag icon
By minimizing coupling in this way, our classes adhere to another class design principle known as the Dependency Inversion Principle (DIP).5 In essence, the DIP says that our classes should depend upon abstractions, not on concrete details.
39%
Flag icon
Software systems should separate the startup process, when the application objects are constructed and the dependencies are “wired” together, from the runtime logic that takes over after startup.