Shop now Shop now Shop now  Up to 70% Off Fashion  Shop all Amazon Fashion Cloud Drive Photos Shop now Learn More Shop now Shop now Shop Fire Shop Kindle Shop now Shop now Shop now

Customer Reviews

4.4 out of 5 stars
4.4 out of 5 stars
Format: Paperback|Change
Price:£16.94+ Free shipping with Amazon Prime
Your rating(Clear)Rate this item

There was a problem filtering reviews right now. Please try again later.

on 31 December 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.
0Comment| 109 people found this helpful. Was this review helpful to you?YesNoReport abuse
VINE VOICEon 27 October 2008
This is a great book, and one which any developer will learn a great deal from. In most respects, it is a five-star book, but... the title is misleading. By rights it should be called "Clean Java Code".

Let me explain: I am an ActionScript developer, and bought this book to improve my code style and structure. For the most part, it has done that: the chapters on naming, comments, functions and classes are absolutely superb. But then, huge swathes of the book are devoted exclusively to Java, and use some fairly complex (and, in my opinion, not very well formatted) code to convey their intention.

I don't generally have a problem with using Java-oriented books to learn more general programming concepts (Martin Fowler's "Refactoring" and O'Reilly's Head-First Design Patterns are both books I would recommend to anyone, regardless of their language-of-choice), but around 1/3rd of Bob Martin's book is virtually impenetrable to anyone who does not already have significant Java experience.

That said, I should re-iterate that this book will be hugely valuable to any programmer. I just wish that they had tried to use a little more pseudo-code and a little less real-world examples, with all of the complexities entailed, and I think a lot could have been done to make the Java code more readable for users of other languages.
33 comments| 89 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 30 November 2008
Clean Code is a valuable book for any programmer's bookshelf. Although a lot of the information can be found in other books on software development, particularly those covering "agile" techniques, the text brings everything into one place with a very readable and enjoyable style. I could've done with this about fifteen years ago, rather than learning many of the lessons the hard way over the years.

The book does have some minor issues though. As mentioned by a previous reviewer, it uses Java exclusively for the examples and assumes you are an experienced Java developer. Some of the examples can be heavy going for those unfamiliar with the language.

The book could also do with a bit more proof-reading. Ignoring a copyright of 2009, the words "it's" and "its" seem to have been swapped throughout the book, "an" replaces "and" in a handful of sentences, and there are even some words in the text that are completely wrong. A bit of shame considering.

Don't let the Java or proof-reading put you off though.
11 comment| 33 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 3 May 2009
Every so often, a book comes along that codifies best practice in a way that manages to illuminate the path from where things are right now, to a better place that we'd rather be -- things like Fowler et al. Refactoring: Improving the Design of Existing Code (Object Technology Series) or the Gang of Four Design patterns : elements of reusable object-oriented software. This is one of those books. And if much of the material is the sort that seems obvious in hindsight -- well, that is the mark of a well written book, to make the concepts that clear.

Taking a series of real world examples -- open source projects with significant user bases, including FitNesse and JUnit -- a series of worked examples take us from good, or at least adequate, code, to a form which is better factored, and easier to read, with the steps along the way clearly marked. Yes, even some of Kent Beck's code is put under the microscope, and carefully polished that extra stage or two more.

The reader is cautioned that, without working long hours to follow these examples, this will be just another of those feel-good books. I don't quite agree -- spending just a little time to follow the transformations, and then reflecting on one's own outpourings should be enough to make this a feel-bad book. All the sins from obscurely named variables to sprawling functions that gaily mix abstraction levels, we've all done them (especially programming in FORTRAN on minicomputers with slow stacks and a rule of thumb that 1 call ~ 40 loc in terms of performance).

The maxim to take from the book is based on Baden-Powell's "Try and leave this world a little better than you found it", and owes to the same school of thought as "whenever you are in the garden, pull at least one weed". The meat of the book is in distinguishing what are the weeds from the intended crop.

So read it, understand the examples, and then refer to it often -- like the other titles mentioned, it is a reference work, and should join them as among the most thumbed on your bookshelf.
0Comment| 5 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 1 April 2014
Experienced coders will recognise lots of good and sensible advice in this book, unfortunately, despite being a book that emphasises readability and attention to detail, poor editing and proof reading often result in statements that are misleading, incomplete or simply incorrect. This should not a problem to experienced readers who will know what was meant, but it is enough to leave the people who should benefit from this book struggling.

Not so obvious is that this is a collection of essays from different authors so can sometimes be incoherent or contradictory.

Deeply disapointing is the chapter and appendices on Concurency. The author states that this is hard and then goes out of their way to prove it, providing very little in the way of positive advice or guidelines.
0Comment| 7 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 6 September 2010
Code blocks in the Kindle version of this book are rendered in a variable-width font, which detracts from their readability. Since the code samples are a very important part of the book, I can't award this a high rating if they are so difficult to read. Code should always be in a fixed-width font.

Also, the occurrence of grammar errors and odd typos is frequent enough to be distracting and irritating. At one point, "startlingly" is written "star-tlingly". Errors that stick out like a sore thumb indicate that this was not proof-read.
11 comment| 9 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 12 April 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.
0Comment| 8 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 21 January 2009
This book has a great summary chapter - Chapter 17. I read this first and decided to read the rest of the book even though there wasn't much I hadn't come across before.

The book really is very readable and covers a lot of ground, generally at intermediate developer level. Advanced developers won't come across anything new, however there is a lot of good advice in one place. This is generally clearly explained with some examples that hint at the level of simplicity that can be achieved in production code with a bit of extra time and a lot of extra effort.

The Law of Demeter is explained with the usual lack of clarity, but there is enough supporting material that I finally understood what it is really about - everything within a scope should be at the same level of abstraction. It was a bit of a revelation when the implications started to sink in.

The Formatting chapter has some interesting insights into the rationale of some of the formatting techniques that I developed naturally over more than 20 years of writing code.

The sub-title reads "A Handbook of Agile Software Craftsmanship". There is the odd nod in the Agile direction, but the text is much more about software craftsmanship than it is about agile, and none the worse for it.

I've already lent the book to one of my colleagues, and I hope to get it back before too long.

Unusually for a Prentice Hall publication the editing is not as good as it should be, and the cover is cheap - it had a distinctive curl after the first reading stint. This is a shame as it's a book that needs to be passed around.
0Comment| 6 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 22 September 2011
I knew this was going to be an excellent book from the moment I heard Uncle Bod describing his ideas of Clean Code at his key note at an ACCU conference. I bought the book there and then, but didn't start reading it until a couple of years later. More recently I got it signed by Uncle Bob at Skillsmatter. After just a few pages it propelled itself into my top three books every programmer should read (behind Kent Beck's Test Driven Development and The Pragmatic Programmer by Andy Hunt & David Thomas) and at the end it's still there.

The chapter on comments is worth the price of the book alone. I have worked in places over the last few years, where comments have been encouraged to explain the code, rather than writing code that explains itself. Another great chapter is the one on functions and the advice to keep them small is especially good and compelling. As I look back over the table of contents now, every chapter that describes how to improve an aspect of code is an absolute mine of good advice.

The final few chapters contain a number of refactorings. One on an application from the ground up and the others on existing code written by other people. This is the only place where the book got gratuitous and I must admit I skipped most of the final refactoring.

The final chapter is a summary of the advice given in the rest of the book and something I will find myself referring to again and again.

If you've read Test Driven Development and The Pragmatic Programmer, make sure you read Clean Code next.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on 5 December 2015
Its mostly common sense, but Uncle Bob had a way of explaining things in great detail without making it boring to read. I also recommend reading Clean Coder and Agile Principles, Patterns and Practices if you like this book. They are also by Robert C Martin.
0Comment|Was this review helpful to you?YesNoReport abuse

Sponsored Links

  (What is this?)