Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)

by Robert C. Martin

This is sometimes called a data transfer object, or DTO.

DTOs are very useful structures, especially when communicating with databases or parsing messa...

They often become the first in a series of translation stages that convert raw data in a database into ob...

Beans have private variables manipulated by getters and setters. The quasi-encapsulation of beans seems to make some OO purists feel better but usually provides no other benefit.

Active Records are special forms of DTOs.

They are data structures with public (or bean-accessed) variables; but they typically have navigational methods like save and find.

Typically these Active Records are direct translations from database tables,...

In any given system we will sometimes want the flexibility to add new data types, and so we prefer objects for that part of the system.

Other times we will want the flexibility to add new behaviors, and so in that part of the system we prefer data types and procedures.

Error handling is important, but if it obscures logic, it’s wrong.

The problem with these approaches is that they clutter the caller.

In a way, try blocks are like transactions.

Try to write tests that force exceptions, and then add behavior to your handler to satisfy your tests.

If you throw a checked exception from a method in your code and the catch is three levels above, you must declare that exception in the signature of each method between you and the catch.

Each exception that you throw should provide enough context to determine the source and location of an error.

Create informative error messages and pass them along with your exceptions. Mention the operation that failed and the type of failure.

However, when we define exception classes in an application, our most important concern should be how they are caught.

In most exception handling situations, the work that we do is relatively standard regardless of the actual cause.

We have to record an error and make sure that we can proceed.

Often a single exception class is fine for a particular area of code.

The information sent with the exception can distinguish the errors.

Use different classes only if there are times when you want to catch one exception and allow th...

This is called the SPECIAL CASE PATTERN

You create a class or configure an object so that it handles a special case for you.

When we return null, we are essentially creating work for ourselves and foisting problems upon our callers.

What exactly should you do in response to a NullPointerException thrown from the depths of your application?

If you are tempted to return null from a method, consider throwing an exception or returning a SPECIAL CASE object instead.

Unless you are working with an API which expects you to pass null, you should avoid passing null in your code whenever possible.

In most programming languages there is no good way to deal with a null that is passed by a caller accidentally.

Clean code is readable, but it must also be robust. These are not conflicting goals.

There is a natural tension between the provider of an interface and the user of an interface.

Third-party code helps us get more functionality delivered in less time.

In learning tests we call the third-party API, as we expect to use it in our application.

Learning tests verify that the third-party packages we are using work the way we expect them to.

One good thing about writing the interface we wish we had is that it’s under our control.

Good software designs accommodate change without huge investments and rework.

We should avoid letting too much of our code know about the third-party particulars.

We manage third-party boundaries by having very few places in the code that refer to them.

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...

What this team did not realize was that having dirty tests is equivalent to, if not worse than, having no tests.

The dirtier the tests, the harder they are to change.

Test code is just as important as production code.

It is unit tests that keep our code flexible, maintainable, and reusable.

Without tests every change is a possible bug.

Readability is perhaps even more important in unit tests than it is in production code.

The first part builds up the test data, the second part operates on that test data, and the third part checks that the operation yielded the expected results.

There are things that you might never do in a production environment that are perfectly fine in a test environment. Usually they involve issues of memory or CPU efficiency. But they never involve issues of cleanliness.

One test should not set up the conditions for the next test.