I first heard of “Uncle” Bob Martin on twitter, a few of the people I was following were discussing how amazing the book Clean Code was and how they would love if some of the other developers they worked with used some of the techniques.
“Uncle” Bob Martin wrote Clean Code: A Handbook of Agile Software Craftsmanship in 2008. The book consists of many different and related topics. Some of the topics Martin wrote about include: naming, using small functions, formatting, some threading, and of course some on testing.
Most of the book can be summarized as if you’re professional you will truly care about the quality of work you do and will not want to leave messy code for somebody else or another time to deal with.
Literally, Bob jumps into meaningful variable names, functions, and comments in the first few chapters and then talk about different techniques for reducing lines of code, reducing code rot, and what happens if tests are ignored and not properly maintained. Bob also says a lot more than simply saying using meaningful names, he says to use easily pronounceable, easily spelled, etc.
I don’t necessarily agree with all of Uncle Bob Martin’s writing: I really agree with Steve McConnell (Code Complete) that a function could be short and be 100 to 200 lines. The average function I write is probably about 20 to 30 lines of code including white space, brackets on a separate line, etc.
One of my favourite concepts is the clear writing about allowing a function or class to only do one task. For example, exceptions should be handled by either another function or a different class depending on the situation. Martin has clearly written one of the best chapters I have ever read on Error Handling even though it didn’t contain a huge amount of code.
One of the most interesting concepts is writing tests for 3rd party code so that you can understand the library’s functionality, and testing how an upgrade would affect the rest of the software. By far, I believe this book is one of the best books I have ever read and has really affected the way I write software.
Author: Brian Cline