Clean Code by Robert C. Martin

A Handbook of Agile Software Craftsmanship

Book Review

So this is my first read of an "Uncle Bob" book. I'm quite impressed. I can't say that I learned anything spectacular. It was more of a book of "yeah, exactly" moments. Quite a few one liners... Some of my favorites.

First, you are a programmer. Second you want to be a better programmer. Good. We need better programmers.

Leave the campground cleaner than you found it. (The boy scout rule).

The first rule of classes is that they should be small. The second rule of classes is that they should be smaller than that.

Don't comment bad code. Rewrite it.

The proper use of comments it to compensate for our failure to express our self in code.

I think that's brilliant! If code requires comments, it's badly named or does not express itself well.

Bob isn't saying all comments are bad, he's just saying that comments shouldn't excuse bad code.  BTW, documentation is not the same as comments... Two very different things.

Comments lie, at least they're capable of it. Code isn't...

He quotes Ward Cummingham (inventor of Wiki).

You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.

Maybe I'm too passionate about coding, but that's motivating to me. "Like the language was made for the problem"!

Code Formatting

A great nice to read... Mostly, "yeah, I know that" moments, but it's great to hear it put in Bob's matter of fact tone. He uses a newpaper article as an example. Tell the overall story (high level) first, get into details later. Your code should be easy to read. Private methods should be close to their first consumer. That way the reader doesn't have to scroll down (far) to find what exactly that method does. Hopefully it's named well enough that they really shouldn't have to go look.

Classes

The first rule of classes is that they should be small. The second rule of classes is that they should be smaller than that.

Nice!

So, I'm working on a MVP view code generator (hope to blog about it very soon). As I was reading this book. I had a class called CSharpPropertyGenerator. In the class I had 3 methods that generated getters for the property. Resharper told me they could be static... SMELL!! Pulled them into thier own class, and it was amazing how much easier the code was to read. Yeah, sure I probably would done it anyway, but I definitely felt Bob looking over my shoulder.

Arguments

The perfect number of arguments for a function is 0. One is OK. Two is questionable, Three... Time to look and see if this should be an it's own class.

 

SOLID

Yep, he's an agile guy, and re-iterates the principles of SOLID.

He's adamant about (DRY), and makes the point that most of the patters of software development are in response to DRY.

Separations of Concerns? You betcha... Once again, no huge "wow" moments, just a nice to read it all in one place. 

Smells and Heuristics

Probably my favorite chapter, in fact it's worth mentioning some of my favorite bullet points.

• Obvious Behavior is unimplemented...
  "The Principle of Least Surprise"
• Incorrect Behavior at Boundries.
  Don't rely on your intuition, rely on unit tests.
• Duplication (need I say more?)
• Base classes depending on their derivatives.
• Feature Envy
• Selector Arguments
  Really liked this one. He used an example function calculateWeeklyPay(bool overTime) and refactored to 3 methods. straightPay, overTimePay and overTimeBonus.
  Much easier to read, and makes much more sense!
• Inappropriate Static.
• Function names should say what they do
• Polimorphism over if/else switch.
  NICE! Would everyone PLEASE jump on this bandwagon?
• Encapsulate Conditionals
  if(ShouldBeDeleted()) instead of if(time.hasExpired() && timer.isRecurrent()).
• Avoid Negative Conditionals
• Functions should descend only on level of abstraction
  

I give this book a B... Nice easy read, that just reinforces things responsible developers probably already know. If anything in this post surprises you, then I'd STRONGLY suggest it. The only negative in this book is that all the source code is java. But I don't consider that a big deal.