Reviews for Clean Code: A Handbook of Agile Software Craftsmanship

1. Useful with misleading title

   Rated 3 out of 5 stars, April 12th, 2010

   This book contains a lot of useful information for software developers regardless of the language in which they are developing. Most of the concepts apply to the majority of object-based programming languages in use today, and in this respect the book achieves its goal.
   
   In order to demonstrate the concepts being discussed, the authors needed to use code examples and Java is the chosen language for this book. As a C# developer I find this a fairly common occurrence in books focussing on Software Engineering in general, and it doesn't usually cause me too many problems. It's generally simple to map the Java concepts across to their equivalents in C#, and many authors keep Java specifics to a minimum to aid this.
   
   Unfortunately, in Clean Code some of the authors lose sight of the fact that this is a Software Engineering book and not a Java development book (either that or the publishers altered the marketing of the book after it had been written). Often, when discussing general concepts, the authors mention Java specific concepts, and in many cases it's clear it wasn't even necessary to do so.
   
   The problem is acerbated by the book title and blurb on the back cover: nowhere does it mention Java. A developer may look inside the book and see Java code, but assume that the accompanying text is general. The reliance on Java knowledge should have been stated clearly in either the title or in the marketing blurb.
   
   Overall, the book is a useful guide to developing maintainable software and I did manage to glean some interesting information from it. But it is less useful than it could have been had some of the authors worked out a way to demonstrate the concepts in a non-language-specific manner. Using Java as an example language is fine - discussing the concepts from a Java-specific viewpoint is not.

2. Mostly Great

   Rated 4 out of 5 stars, January 12th, 2010

   There's no denying that this is a great book. It's easy to read, has some great examples and is a must for every developer. I will certainly be keeping this title on my desk and referring back to it regularly. Having 15 years experience of software development, there wasn't much that I found to be startlingly new, but it was nice to have all the guidelines listed in one excellent source. I have certainly cleaned up my code since reading this book and corrected some sloppy practices that I had fallen in to.
   
   That said, there are a number of reasons why this could not be given a 5-start rating:
   
   Firstly the chapters on concurrency seem like a waste of space in this title. There are many better books on writing concurrent code and I didn't find anything in the concurrency chapters specific to clean code that wasn't covered elsewhere in the book.
   
   Secondly, I felt that in some cases the book was preaching a single correct way of working for some highly subjective and debatable coding styles. While I respect the author's opinion on this, a bit more time spent on debating the different options might have helped with understanding the authors intentions and point of view. Since reading this book I've tried to convert a number of colleagues to the rules in this book but have often found the lack of advantages and argument points a real hinderance in getting them on board.
   
   Finally, the case study chapters that form the second half of this book could be better. The introduction promise these to be 'intensely challenging, taking days'. I was expecting some really challenging puzzles and questions to work through. Instead you are just presented with before and after style listings and a brief discussion of the rationale used to transform from one to the other. As a strong Java developer, the code was easy to follow and the refactorings quite obvious. I managed to work my way through all the case studies in a couple of hours with no problem - slightly disappointing given the promise of the introduction.

3. Scattergun list of pet peeves

   Rated 2 out of 5 stars, December 12st, 2009

   This book is best described as a list of "pet peeves" by the authors. I stress that this book is mainly written by a collection of authors - and not Robert C. Martin - because this is not stated in any promotional material and appears as an unwelcome surprise in the introduction of many chapters.
   
   The first chapter pledges a lot and is very motivational - continuing the promise of the back cover "you will be challenged to think about what's right about that code, and what's wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft." However, for the remainder of the book, the authors never quite get out of their individual rants and fail to provide any great insights beyond the obvious - concluding with a collection of scattergun practices that are more elegantly described in other books.
   
   The value of the second part of the book - described as "several case studies of increasing complexity" - is not particularly evident. I found the Arg (first) and SerialDate (last) cases to be needlessly long. Everything there could be described in isolation. I had expected the second part of the book to be left as a series of short examples for the reader to work on - in the style of Java Puzzlers - but alas, it was a tour of some recent open source contributions that the author wishes to share with the reader.
   
   The section on Concurrency was particularly shocking. The author appears completely oblivious to "Java Concurrency in Practice" by Doug Lea - discussing the 1999 predecessor by introducing it alongside a derogatory statement about maturity. Not only are the concurrency chapters skin deep, but I question why these chapters even made it into this book. Further evidence that the authors set out with no specific agenda when compiling the book, and have ended up with repetitive, sweeping generalisations that deliver only wholesale value across the board.

4. A turning point in a developer outlook

   Rated 5 out of 5 stars, December 12th, 2009

   I really enjoyed this read, mainly because it makes a lot or sense and also because I realise that I wasn't the only one who was passionate about clean code. For me as a developer reading this book I realised an important thing, and that was if there are any mistakes it is my fault. This could be down to a multiple of reasons, but as the professional I must take responsilibility for what I build therefore I better make it good!
   
   I think anyone aspiring to be a developer must read this book, I also know a lot of 'senior' developers that should also seriously considering reading this book. You may not agree with everything, but you still need to know about the principals.
   
   
   
   

5. a must for java developers

   Rated 5 out of 5 stars, November 12th, 2009

   I bought this book and Implementation Patterns (Addison-Wesley Signature) at the same time and read them at the same time. The contrast could not be greater. This book has lots of examples and although much bigger is it is a real page turner. I failed to get anything but frustration out of the other book.
   
   In the last day I attempted to put the books advice into practice on some security code. Get it working, then re-work it for clarity using the practical advice of the book. The book very much helped to spot complexity in the initial implementation and extensively refactor the code into something more obvious, easier to document and more re-usable.
   
   There were a couple of minor things that I disagreed with. With the author putting so much down with a stamp of authority there is going to be at least one thing in the book for everyone to disagree with. That does not distract from giving it full marks though and recommending it one to read and possibly re-read.