4 ms·

This won’t win me any friends, but I personally think that Clean Code is one of the most dangerous programming books to be released in the last decade. There’s

This won’t win me any friends, but I personally think that Clean Code is one of the most dangerous programming books to be released in the last decade. There’s a lot of good advice in the book, but it is written by and for Java programmers, and it comes with its share of risks if you take its advice. If you’re developing in a dynamically typed OO language like Ruby, it’s almost always bad advice to follow Clean Code. There are performance considerations even with Java to following some of the advice given. With Objective C, the suggestions are just silly. With languages that emphasize some level of functional programming (including Ruby and even C# to a degree), the suggestions are counter-productive and produce code that is unnecessarily obfuscatory. Yes, it’s good to have short, readable, meaningful methods. Reducing method size too much, though, can result in code that you have to follow through many objects in order to understand the logic. If you follow Martin’s advice enough, you will end up with lots of very short methods on lots of very small objects—and have a hard time understanding just how your program fits together. If Martin were a better writer, or had expanded his horizons beyond Java when he had written this book, he may have written something profound—still dangerous, but profound. Instead, he wrote Clean Java and either he or his publisher thought it would sell more as Clean Code. My advice is to ignore the book—unless Martin comes out with a second edition that takes what he has learned in the last few years since leaving behind Java and applies it to really make a book that describes clean code.

rluhar 13y ago
I agree with your premise that Clean Code is not a suitable book for all programmers / and or all languages. But a good amount of "enterprise" software is written in Java. And, in "enterprise land" (where I currently live), there are lots of mediocre, inexperienced or untrained programmers for whom the advice in Clean Code is useful. I have had to try and clean up functions that were two thousand lines long (in Java), had lots of side effects, and took in seven parameters. Oh boy did I wish the developer had read Clean Code. I agree with your premise that the book is not relevant to those who work in dynamic or functional programming languages. Frankly, I don't think they are not the intended audience. I think it is a little hyperbolic to call it the "one of the most dangerous programming books released in the last decade".
- derefr 13y ago
  > those who work in dynamic or functional programming languages ... are not the intended audience I don't understand how a book that professes to be top-down advice about software craftsmanship as a discipline can be intended only for a specific subset of programmers. Shouldn't choosing a language be as much a part of software craftsmanship as how you use that language? It's like writing a book entitled "Good Woodworking" which implicitly assumes you'll be using only double-clawed hammers[1]. Wouldn't you expect a book called "Good Woodworking" to start with a chapter on good tools? [1] http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
  - halostatue 13y ago
    Which is why I’ve said (ever since I read it the first time) that Clean Code wouldn’t annoy me half as much if it were simply called Clean Java. It wouldn’t sell as many copies that way, though. Probably.
paragraft 13y ago
I came here to say something similar, but you took the words out of my mouth. My experience reading through it was it was a mix of good advice with some questionable advice, some advice that was really only good for Java, and some advice that was terrible. The problem is it's pitched at an audience that may not be able to discern the differences between the above. The multiple authors (on a per-chapter basis) doesn't help. Generally speaking, the earlier chapters were better, but my advice would echo yours: give it a miss, especially if you're not working in Java.
jasonlotito 13y ago
> If you follow Martin’s advice enough, you will end up with lots of very short methods on lots of very small objects—and have a hard time understanding just how your program fits together. I have never found this to be the case. Quite the contrary, in fact. Far too many objects that do way to much, or functions that do X and Y. Indeed, I'm puzzled by your statement: > Yes, it’s good to have short, readable, meaningful methods. Reducing method size too much... Which directly contracts this: > If you follow Martin’s advice I guess the key word is 'enough', which is really just bad wording. "If you don't follow Martin's advice" is better. The qualifier here is you don't make short methods for the sake of having short methods. You make methods as short as they need to be to do that thing they promise to do. So then we come to it: either you support having your methods do more than they should, doing more than one thing and having side effects, or you support Martin's suggestions. And yes, it really is that black and white. Sure, you could suggest that following his advice "enough" leads you to nothing but one line methods, but that would be silly.
- halostatue 13y ago
  No, it isn’t that black and white. Many of Martin’s suggestions are silly, especially when applied to languages that are more expressive (like Ruby, CoffeeScript) or otherwise have no relationship to Java. I distinctly remember arguments with people who were reading Clean Code at the time who really believed that one-line methods really were the ideal. The trick is knowing what does “doing more than they should” actually mean? If you follow Clean Code as I’ve seen some people follow it (including the Ruby dev shop I mentioned elsecomment), you will end up having substantially larger interfaces at the cost of understanding just what it is that your program is supposed to do in the first place. I’ve dealt with programs written the Clean Code way (an explosion of methods, classes, and objects), as well as programs written with too much going on in one place (e.g., 2+kloc functions). Neither is fun to deal with, but it’s generally easier to assimilate the basic business purpose of the 2+kloc function than something that has a larger interface surface than it needs to have.
  - joshka 13y ago
    Your assertions are interesting. I'd like to see some concrete examples of where you've seen this actually play out to make not well understood code. Having recently read Clean Code as a C# dev, I feel the missing piece in this conversation is that the advice of small methods needs to be taken together with the idea that things should do one thing, and should be composed of items at the same level of abstraction. I feel the idea is hard to defend on its own, but with the other ideas quite easily defended. I'm also curious about the performance problems you've mentioned above.

rluhar 13y ago

I agree with your premise that Clean Code is not a suitable book for all programmers / and or all languages. But a good amount of "enterprise" software is written in Java. And, in "enterprise land" (where I currently live), there are lots of mediocre, inexperienced or untrained programmers for whom the advice in Clean Code is useful. I have had to try and clean up functions that were two thousand lines long (in Java), had lots of side effects, and took in seven parameters. Oh boy did I wish the developer had read Clean Code. I agree with your premise that the book is not relevant to those who work in dynamic or functional programming languages. Frankly, I don't think they are not the intended audience. I think it is a little hyperbolic to call it the "one of the most dangerous programming books released in the last decade".

derefr 13y ago
> those who work in dynamic or functional programming languages ... are not the intended audience I don't understand how a book that professes to be top-down advice about software craftsmanship as a discipline can be intended only for a specific subset of programmers. Shouldn't choosing a language be as much a part of software craftsmanship as how you use that language? It's like writing a book entitled "Good Woodworking" which implicitly assumes you'll be using only double-clawed hammers[1]. Wouldn't you expect a book called "Good Woodworking" to start with a chapter on good tools? [1] http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
- halostatue 13y ago
  Which is why I’ve said (ever since I read it the first time) that Clean Code wouldn’t annoy me half as much if it were simply called Clean Java. It wouldn’t sell as many copies that way, though. Probably.

paragraft 13y ago

I came here to say something similar, but you took the words out of my mouth. My experience reading through it was it was a mix of good advice with some questionable advice, some advice that was really only good for Java, and some advice that was terrible. The problem is it's pitched at an audience that may not be able to discern the differences between the above. The multiple authors (on a per-chapter basis) doesn't help. Generally speaking, the earlier chapters were better, but my advice would echo yours: give it a miss, especially if you're not working in Java.

jasonlotito 13y ago

> If you follow Martin’s advice enough, you will end up with lots of very short methods on lots of very small objects—and have a hard time understanding just how your program fits together. I have never found this to be the case. Quite the contrary, in fact. Far too many objects that do way to much, or functions that do X and Y. Indeed, I'm puzzled by your statement: > Yes, it’s good to have short, readable, meaningful methods. Reducing method size too much... Which directly contracts this: > If you follow Martin’s advice I guess the key word is 'enough', which is really just bad wording. "If you don't follow Martin's advice" is better. The qualifier here is you don't make short methods for the sake of having short methods. You make methods as short as they need to be to do that thing they promise to do. So then we come to it: either you support having your methods do more than they should, doing more than one thing and having side effects, or you support Martin's suggestions. And yes, it really is that black and white. Sure, you could suggest that following his advice "enough" leads you to nothing but one line methods, but that would be silly.

halostatue 13y ago
No, it isn’t that black and white. Many of Martin’s suggestions are silly, especially when applied to languages that are more expressive (like Ruby, CoffeeScript) or otherwise have no relationship to Java. I distinctly remember arguments with people who were reading Clean Code at the time who really believed that one-line methods really were the ideal. The trick is knowing what does “doing more than they should” actually mean? If you follow Clean Code as I’ve seen some people follow it (including the Ruby dev shop I mentioned elsecomment), you will end up having substantially larger interfaces at the cost of understanding just what it is that your program is supposed to do in the first place. I’ve dealt with programs written the Clean Code way (an explosion of methods, classes, and objects), as well as programs written with too much going on in one place (e.g., 2+kloc functions). Neither is fun to deal with, but it’s generally easier to assimilate the basic business purpose of the 2+kloc function than something that has a larger interface surface than it needs to have.
- joshka 13y ago
  Your assertions are interesting. I'd like to see some concrete examples of where you've seen this actually play out to make not well understood code. Having recently read Clean Code as a C# dev, I feel the missing piece in this conversation is that the advice of small methods needs to be taken together with the idea that things should do one thing, and should be composed of items at the same level of abstraction. I feel the idea is hard to defend on its own, but with the other ideas quite easily defended. I'm also curious about the performance problems you've mentioned above.