- ISBN13: 9780132350884
- Condition: NEW
- Notes: Brand New from Publisher. No Remainder Mark.
Product Description
Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.
Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin has teamed up with his colleagues from Object Mentor to distill their bes… More >>
Clean Code: A Handbook of Agile Software Craftsmanship
Tags: Agile, Clean, Code, Craftsmanship, Handbook, Software
#1 by Nicholas Dwork on February 10, 2010 - 10:49 pm
The book is sparse with information. The main thesis of the code could be summarized in a simple phrase: write short functions and use descriptive names. Like many other books on software style, this author takes his style to the extreme. His ideal function would contain three or four lines, including the prototype. Although beneficial in some sense, this would lead to layers upon layers of functions in even the simplest program. This, in itself, would be a cumbersome and very messy coding style. To accomodate this coding style, the author suggests abstracting the innards of the code. While this does indeed make the code LOOK simpler, it’s much harder to understand the intent of the programmer since the details (like what the input variables are) are hidden from the function caller. One must then rely on the descriptive names for all of their information, and if they want to verify that the function is indeed doing what the name states, then they must go diving through many many layers of function calls. For simple ideas (like making a notepad application), this may be ok, since a function name really could accomodate most of the intent of the function. But for more complicated routines, like takeTheNormalizedCrossCorrelationBetweenAKernelOfImageAAndASubRegionOfImageB, this idea of capturing the intent in the function’s name seems less applicable.
I highly recommend NOT purchasing this book.
Rating: 1 / 5
#2 by Roberto on February 11, 2010 - 12:36 am
The author fails to recognize that creating clean code is a balancing act, so he proceeds to fall off of a couple of big cliffs: 1) Advocating creating a million tiny functions each of which does almost nothing, and 2) Variable and function names that are so long they form detailed descriptions. While its true that with super long names and trivially small functions its possible to write basically self-documenting code, there is a major sacrifice of overall clarity. While each function on its own may be understandable, if you have split relatively simple processing across 6 different functions, you have greatly reduced the signal-to-noise ratio of the overall project. Each function you have created also now needs to have an interface maintained in both caller and function, and in C++ you will additionally need to maintain all of these interfaces in separate header files. There are many cases where this is a worthwhile strategy (re-use of functions, encapsulation of business logic, etc), but the author takes it way past the point where it makes sense and the result is code that is tedious to read, understand, and maintain. As far as the long names go, I personally don’t want to wade through 30 character names for every variable or function, since it absolutely removes the ability to take something in at a glance (this name explosion seems to be an unfortunate trend in the java world). Lets be realistic; the vast majority of variables and functions can be effectively and clearly named with two words instead of a run-on sentence for a name. There are other questionable patterns he advocates, such as redundant Interface declarations for creating a class: E.g. the base interface might be MyWidget, and the instantiated class is named MyWidgetImpl. If you don’t NEED polymorphism this is only going to create confusion, and if you DO need polymorphism then using a generic suffix of “Impl” is pretty much unhelpful. I would give this book a miss, doubly so if you’re not working in java.
Rating: 1 / 5
#3 by Steven Koh on February 11, 2010 - 1:49 am
I would have given it 5 stars if I didn’t read the Code Complete 2 by Steve McConnell.
This book is clear and concise for readers of all levels of programming skills.
I would recommend Code Complete 2 along with this book
Rating: 4 / 5
#4 by CyberK on February 11, 2010 - 4:43 am
This book contains a lot of text about importance of good code and how hard it is to write one. But there is no concrete examples. A lot of “blah blah blah.. company came to
because they did
, this is very bad.. blah blah blah…” But there is no solutions in this book of how to avoid
and not do
but instead do
to solve the same problem.
Rating: 1 / 5
#5 by W Boudville on February 11, 2010 - 6:44 am
The book contains much useful advice for professional programmers. A bunch of software authors have contributed the book’s chapters.
There is one place where I disagree. Where it talks about having commented out code in your source code file. Yes, this often leads to obsolete code, even as commented out code, precisely because as you change various things like variables in the active code, this has no effect on the commented out portions. The book recommends that you simply delete the latter, since you can always retrieve it later via your version control system, which you should certainly be using anyway.
But the book’s reasoning is flawed. Simply having the commented out code stored in the version control system is of little use. Out of sight, out of mind. How many programmers are actually going to troll thru previous versions of the file looking for that particular code? For one thing, they have to somehow know or suspect that it might exist. If the programmer currently working on the file is not the author of the commented out code, then there is little likelihood that she will even be aware of this. But even if she was the author of the original code, what if she forgets?
The book’s recommendation is an idealisation. The pragmatic reality is that you should, sparingly, keep commented out code in your source files, precisely because it is there in front of you, retaining mindshare, whenever you edit the file. I say sparingly, because you should only do this for crucial code blocks. How to determine this? Well, that is part of your expert knowledge.
Rating: 4 / 5