In this post–and maybe in future ones–I'll share some of the notes I've taken about the book.
Comment Only What The Code Cannot Say
Original article by Kevlin Henney, here.
[…] to reduce the risk of overlooking any comments of genuine value, comments should be treated as if they were code. Each comment should add some value for the reader, otherwise it is waste that should be removed or rewritten.
There are lots of articles about how Comments Are Evil™ but this one doesn't (just) demonize them, it defines the only situation where they may exist:
Any shortfall between what you can express in code and what you would like to express in total becomes a plausible candidate for a useful comment. Comment what the code cannot say, not simply what it does not say.
What I gather from the article is that I should try to be as expressive as possible with the code before considering adding a comment.
Don't Be Afraid to Break Things
Original article by Mike Lewis, here.
I really like this article. What it wants to tell us is:
Don't be afraid of your code.
And I'll stop the quote there, otherwise I'll end up quoting the whole thing.
The take away is that, if we let the fear of breaking things slip into the project, then the technical debt will pile up since we won't be able to change, improve, remove, refactor, code that needs intervention.
We have tests in place, we shouldn't be worried about renaming a method, or changing how a service works even if that may break code out of the scope of the feature we're working at a specific moment.
The Boy Scout Rule
Original article by Uncle Bob, here.
The Boy Scouts have a rule: "Always leave the campground cleaner than you found it." If you find a mess on the ground, you clean it up regardless of who might have made the mess.
This article is very straight forward.
Indeed the act of leaving a mess in the code should be as socially unacceptable as littering. It should be something that just isn't done.