I'm still amused by claims that the book is dogmatic when these paragraphs are in the opening chapter:
> Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and professional. But don’t make the mistake of thinking that we are somehow “right” in any absolute sense. There are other schools and other masters that have just as much claim to professionalism as we. It would behoove you to learn from them as well.
> Indeed, many of the recommendations in this book are controversial. You will probably not agree with all of them. You might violently disagree with some of them. That’s fine. We can’t claim final authority. On the other hand, the recommendations in this book are things that we have thought long and hard about. We have learned them through decades of experience and repeated trial and error. So whether you agree or disagree, it would be a shame if you did not see, and respect, our point of view.
Generally dogmatic people don't say, in short, "We could be wrong, we don't think we are, but go see what other people have to say, too.".
The claim is not that the book is dogmatic, but that its worshippers (for lack of a better word) are. The infamous Design Patterns book, despite having a similar "disclaimer", has had a similar effect.
It's dogmatic in the sense that it often pursues some point (such as very short functions) to the level of a dogma, without much regard for the benefit accrued.
And no evidence. Other programming books cite academic or case studies. Martin's book is essentially a long appeal to authority to himself. If he'd written like, Quake or something I might buy it, but he hasn't.
Why? How strong would their [0] arguments be? Is it worth increasing the size of what was already (had to look this up) a 464 page text to include weak arguments about other people's views? Or, you know, people could actually read the giant disclaimer (it was more than those two paragraphs, I just copied them here) and then take it at face value, go learn other ideas about programming. Practice your own judgement.
No book, no philosophy, no technique, no programming language, no ChatGPT can ever remove the need for the programmer to think for themselves and determine their own approaches to programming and which approaches are appropriate for which programs.
[0] I keep using they and their, there were multiple authors for the book. Several chapters were written by people other than Martin.
I imagine the strength of their arguments would be approximately related to the strength of said arguments merits / demerits. You don't have to present an unyielding argument if your goal is to educate your reader and help them to reach an informed position.
He's saying he expected more, coming from a different background with a culture of rigor.
If this verbiage is only in the introduction, it will not carry much weight. People, and especially IT people like rules, that you can indiscriminately apply.
If people claim to read a book and skip chapter 1, did they really read the book? I'd say no, they only read part of it. It's not the authors' fault that people skip a chapter that generally provides the context for reading the rest of the book. That's on them. Don't be foolish, learn the context of what you're reading before you read it. That is what should be encouraged.
My point is that people are better at remembering and applying specific rules. And it is my perception that people involved in software development like explicit rules. This is partly due to the exponential growth (and thus low level of experience) and also because it feels more objective.
“Code should be readable” is a higher level goal that is inevitably subjective, so it is harder to enforce than for instance, DRY.
> Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and professional. But don’t make the mistake of thinking that we are somehow “right” in any absolute sense. There are other schools and other masters that have just as much claim to professionalism as we. It would behoove you to learn from them as well.
> Indeed, many of the recommendations in this book are controversial. You will probably not agree with all of them. You might violently disagree with some of them. That’s fine. We can’t claim final authority. On the other hand, the recommendations in this book are things that we have thought long and hard about. We have learned them through decades of experience and repeated trial and error. So whether you agree or disagree, it would be a shame if you did not see, and respect, our point of view.
Generally dogmatic people don't say, in short, "We could be wrong, we don't think we are, but go see what other people have to say, too.".