4 ms·

This article[1] also explains some complaints. 1: https://qntm.org/clean https://qntm.org/clean

skinkestek 5y ago
From the comments of that article: I reread your breakdown of the FitNesse code example a few times and I felt less and less generous about the analysis each time. Here's two and half questions: 1) If private fields are NOT to be considered implicit arguments to every private method, what exactly are they for? (And if they should not be modified, why would they be anything other than 'final'?) 2) Why do you consider Martin's definition of side-effect, which speaks of 'global state' and 'unexpected changes' to include changes to private members of the class in functions that document those changes via their signature? You could answer those uncharitably and make Uncle Bob look bad, or you could answer them charitably and then his code makes sense. I also have to say I don't understand how 'illegible trash' is remotely an appropriate description. This is as good as just about anything I've seen in actual production work in 10 years. It's extremely readable and quite testable. There are nits to pick (and you've done an excellent job of that), but for some part of those at least I feel like they're to be picked with 2008 Java API and coding standards rather than the author. I can't see that reading this book would be a net negative for 95% of people writing OO code. If you also don't know of a better book either, I'm stumped as to why you'd stop recommending it. Finally, it looks to me like there's people out to get Uncle Bob cancelled for not being on-board with a certain political invasion of software that's going around at the moment (you can already see a comment calling him 'a terrible human'), so I'm somewhat suspicious of ulterior motives here. If that's not your intent, my apologies. I did like this article in general and found it to be plenty insightful, so I'd love to read more from you.
- nemetroid 5y ago
  Funnily enough, I don't think the quoted comment makes a charitable interpretation of the article. > Why do you consider Martin's definition of side-effect, which speaks of 'global state' and 'unexpected changes' to include changes to private members of the class in functions that document those changes via their signature? In Martin's definition, the first example of a side effect is "unexpected changes to the variables of its own class". Perhaps the argument being made here is that the changes aren't unexpected, but in that case, the article is very clear in that it considers them unexpected.
lowbloodsugar 5y ago
I have also been writing software for a while, and I agree with most of Martin's claims that qntm sites in that article. But I also agree that the example code is utter crap. It violates most of the rules that Martin just gave in the chapter. Now, having written technical documentation myself, and even "Welcome interns" docs, I understand that writing good examples of good code is quite hard. But on the other hand, if one is writing a book about good programming then take the time to write examples that actually demonstrate what was claimed in the preceding pages! Like, it would be better to have a comment saying "Imports elided for brevity and printing costs" rather than writing wildcard imports.

From the comments of that article: I reread your breakdown of the FitNesse code example a few times and I felt less and less generous about the analysis each time. Here's two and half questions: 1) If private fields are NOT to be considered implicit arguments to every private method, what exactly are they for? (And if they should not be modified, why would they be anything other than 'final'?) 2) Why do you consider Martin's definition of side-effect, which speaks of 'global state' and 'unexpected changes' to include changes to private members of the class in functions that document those changes via their signature? You could answer those uncharitably and make Uncle Bob look bad, or you could answer them charitably and then his code makes sense. I also have to say I don't understand how 'illegible trash' is remotely an appropriate description. This is as good as just about anything I've seen in actual production work in 10 years. It's extremely readable and quite testable. There are nits to pick (and you've done an excellent job of that), but for some part of those at least I feel like they're to be picked with 2008 Java API and coding standards rather than the author. I can't see that reading this book would be a net negative for 95% of people writing OO code. If you also don't know of a better book either, I'm stumped as to why you'd stop recommending it. Finally, it looks to me like there's people out to get Uncle Bob cancelled for not being on-board with a certain political invasion of software that's going around at the moment (you can already see a comment calling him 'a terrible human'), so I'm somewhat suspicious of ulterior motives here. If that's not your intent, my apologies. I did like this article in general and found it to be plenty insightful, so I'd love to read more from you.

nemetroid 5y ago
Funnily enough, I don't think the quoted comment makes a charitable interpretation of the article. > Why do you consider Martin's definition of side-effect, which speaks of 'global state' and 'unexpected changes' to include changes to private members of the class in functions that document those changes via their signature? In Martin's definition, the first example of a side effect is "unexpected changes to the variables of its own class". Perhaps the argument being made here is that the changes aren't unexpected, but in that case, the article is very clear in that it considers them unexpected.

lowbloodsugar 5y ago

I have also been writing software for a while, and I agree with most of Martin's claims that qntm sites in that article. But I also agree that the example code is utter crap. It violates most of the rules that Martin just gave in the chapter. Now, having written technical documentation myself, and even "Welcome interns" docs, I understand that writing good examples of good code is quite hard. But on the other hand, if one is writing a book about good programming then take the time to write examples that actually demonstrate what was claimed in the preceding pages! Like, it would be better to have a comment saying "Imports elided for brevity and printing costs" rather than writing wildcard imports.