Hacker News Reader

Comment by DanielVZ | Hacker News Reader

Clean Code was one of the first books I read as a History student trying to become a self taught developer. From my point of view, coming from the rigor of historiography, the book was inconsistent and dogmatic. Still I took it as a replacement to talking with an experienced engineer, because that’s how it felt and most of the principles were fine when not taken to the extreme.

But now in my career I’ve seen awfully unnecessarily complex code in the name of the SOLID principles and others like DRY. Other times completely misunderstanding what the principles stand for and applying them in hand wavy ways.

This is a personal stretch, but even the marketing behind the principles is a bit of a red flag for me (Clean Code, SOLID, UNCLE BOB????). To me it sounds like someone made a career out of this.

I wish we had a better book to recommend to newcomers.

View on HN

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.

Quoting the person I responded to, who wrote:

> the book was inconsistent and dogmatic.

How do you square that with:

> The claim is not that the book is dogmatic

You are claiming they didn't write what they wrote.

This is kind of like a recipe book opening with a disclaimer saying "Some of these recipes might make you ill."

Immediately followed by many, many pages recommending that you add asbestos for flavoring, or lead for color.

A disclaimer doesn't change whether something is done or not. And it's a rather small fig leaf compared to the rest of the book.

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.

I didn't remember that in the introduction. But if that was the case the book should've included more counterexamples and a less imperative language.

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.

> Why? How strong would their [0] arguments be?

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.

I've recommended it before (I think there's even a blog post of mine written in direct response to this article floating around somewhere): A Philosophy of Software Design is really good.

It isn't so concerned with all of the details about what exact decisions you should make ("how many lines should my function have?" etc), but rather the high-level design choices that go into those decisions. A lot of the book is spent on the philosophy of interfaces, which is the author's way of describing the boundaries between a piece of code and its caller.

It's written by John Ousterhout, of Tcl fame (among many other things) based on his own experience, but also his attempts to teach software engineering to students, and the techniques that worked well for those students in practical situations, so I think it's fairly well grounded in actual advice.

I was also thinking about this book when I read that article. It's really an excellent book and it's condensed and because it's written by an expert in teaching it's easy to grasp.

It's also recommended in this article:

"Update, 2020-12-19 After suggestions from comments below, I read A Philosophy of Software Design (2018) by John Ousterhout and found it to be a much more positive experience. I would be happy to recommend it over Clean Code".

Haha, I read the article immediately after this comment and saw that comment, I think it wasn't there last time I read it (so presumably before the end of 2020!). I agree that it's probably not as good for complete beginners, but it's really good for anyone with a bit of experience looking to move from "I'm just writing code" to "I'm writing actual software".

Honestly anytime I run into someone spouting something "Uncle Bob" has tried to propagate in our industry while trying to sell books and his "knowledge" I find that it is safe to assume they are probably a perpetual junior level developer.

Which SOLID principles have you found issues with, either theoretically or in practice? They still seem like broadly sensible principles to me.

For example the Open Closed principle is often times used to justify a plethora of inheritance chains rather than having a more generic class that can handle cases based on some parameter. Specially when all a subclass does is modify some class attribute or change some implementation by one line. Obviously some times it's good to apply the principle, but not EVERY time it fits.

There are literally hundreds of better books for newcomers. As just one, I would mention Programming Pearls by Jon Bentley. I would say it communicates a much more healthy approach to the craft.

Good points, interesting context coming from a history student and now with some experience, I'd like to read more on your thoughts if you have a blog.

Thanks! I haven't written much really. I killed my personal site some months ago, and this is the only public blog post I have now, but it's more related to my current side-project and how I got into programming:

https://pomasearch.com/blog/why-is-this-site-named-poma-and-...

I always recommend "The Pragmatic Programmer" (Hunt, Thomas) and "Code Complete" (McConnell).

Reply on news.ycombinator.com