More Clean Code

Some more quotes from Clean Code

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

I like this idea. I have heard them called Null Objects before as well. Every time I read about them they sound like such a great idea. I struggle many times to implement them though. I think null pointer exceptions are difficult to keep from happening so I am going to keep trying to learn how to use these guys.

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.

I like this idea of boundaries. We are trying to figure out how one team can customize the work of another team. My wish is that the customization team would create a boundary around our code and write all of their customizations around that boundary. This would allow us to continue to refactor and improve our code without worrying about breaking them.

It is unit tests that keep our code flexible, maintainable, and reusable. The reason is simple. If you have tests, you do not fear making changes to the code! Without tests every change is a possible bug. No matter how flexible your architecture is, no matter how nicely partitioned your design, without tests you will be reluctant to make changes because of the fear that you will introduce undetected bugs.

This is a great quote. I can remember many times the fear they are talking about. I was scared to make things better and just kept hacking away making things harder to understand.

Perhaps a better rule is that we want to test a single concept in each test function. We don’t want long test functions that go testing one miscellaneous thing after another.

I worked on the mother of ugly tests the other day. It had a crazy event callback that would allow it to test fourteen completely different scenarios all in the same test. It was so complicated and hard to understand.

Unit tests should be written just before the production code that makes them pass. If you write tests after the production code, then you may find the production code to be hard to test. You may decide that some production code is too hard to test. You may not design the production code to be testable.

I have heard this argument so many times that X type of code is just not testable. I agree with the author. We just sometimes choose to write code in a way that is not testable.