[throwaway1004]

That reference link is a wild ride of unqualified, cartoonish passive-aggression, the cute link to the author's "swag" is the icing on the cake.

Concidentally, I encountered the author's work for the first time only a couple of days ago as a podcast guest, he vouches for the "Dirty Code" approach while straw-manning Uncle Bob's general principles of balancing terseness/efficiency with ergonomics and readability (in most, but not all, cases).

I guess this stuff sells t-shirts and mugs /rant

[Arainach]

>Uncle Bob's general principles of balancing terseness/efficiency with ergonomics and readability (in most, but not all, cases).

Have you read Uncle Bob? There's no need to strawman: Bob's examples in Clean Code are absolutely nuts.

Here's a nice writeup that includes one of Bob's examples verbatim in case you've forgotten: https://qntm.org/clean

Here's another: https://gerlacdt.github.io/blog/posts/clean_code/

[throwaway1004]

>Have you read Uncle Bob?

Yes, I have read Uncle Bob. I could agree that the examples in the book leave room for improvement.

Meanwhile, the real-world application of these principles and trial-and-error, collectively within my industry, yields a more accurate picture of it's usefulness.

Even the most click-bait'y criticisms (such as the author I referenced above) involve zooming in on it's most-controversial aspects, in a vacuum, without addressing the core principles and how they're completely necessary for delivering software at scale, warranting it's status as a seminal work.

"...for the obedience of fools, and the guidance of wise men", indeed!

edit - it's the same arc as Agile has endured:

1. a good-faith argument for a better way of doing things is recognised and popularised.

2. It's abused and misused by bad actors/incompetents for years (who would not have done better using a different process)

3. Jaded/opportunistic talking heads tell us it's all garbage while simultaneously explaining that "well, it would be great if it wasn't applied poorly..."

[Arainach]

>involve zooming in on it's most-controversial aspects, in a vacuum, without addressing the core principles and how they're completely necessary for delivering software at scale, warranting it's status as a seminal work.

It's not "zooming in" to point out that the first and second rules in Bob's work are "functions should be absurdly tiny, 4 lines or less" and that in the real world that results in unreadable garbage. This isn't digging through and looking for edge cases - all of the rules are fundamentally flawed.

Sure, if you summarize the whole book as "keep things small with a single purpose" that's not an awful message, but that's not the book. Other books have put that point better without all of the problems. The book is full of detailed specific instructions, and almost all of the specifics are garbage that causes more bad than good in the real world.

Clean Code has no nuance, only dogma, and that's a big problem (a point the second article I linked calls out and discusses in depth). There are some good practices in it, but basically all of its code is a mistake that is harmful to a new engineer to read.

[throwaway1004]

>Sure, if you summarize the whole book as "keep things small with a single purpose" that's not an awful message, but that's not the book.

Assuming that you have read the book, I find it odd that you would consider that to be the steel-man a fan of this work would invent, it considers considerably more ground than that:

- Prioritise human-readability

- Use meaningful names

- Consistent formatting

- Quality comments

- Be DRY, stop copy-pasting

- Test

- SOLID

All aspects of programming, to this day, I routinely see done lazily and poorly. This rarely correlates with experience, and usually with aptitude.

>Clean Code has no nuance, only dogma, and that's a big problem (a point the second article I linked calls out and discusses in depth)

It's opinionated and takes it's line of reason to the Nth degree. We can all agree that the application of the rules require nuance and intelligence. The second article you linked is a lot more forgiving and pragmatic than your characterisation of the issue.

I would expect the entire industry to do a better job of picking apart and contextualising the work, after it made an impact on the industry, than the author himself could or ever will be capable of.

My main problem is the inanity of reactionary criticism which doesn't engage with the ideas. Is Clean Code responsible for a net negative effect on our profession, directly or indirectly? Are we correlating a negative trend in ability with the influence of this work? What exactly are "Dirty Code" mug salesmen proposing as an alternative; what are they even proposing as being the problem, other than the examples in CC are bad and it's easy to misapply it's principles?

[Arainach]

>We can all agree that the application of the rules require nuance and intelligence

Except Uncle Bob, it seems, as evidenced by his code samples and his presentations in the years since that book came out. That's my objection. Many others have presented Bob's ideas better in the last 19 years. The book was good at the time, but we're a decade past when we should have stopped recommending it. Have folks go read Ousterhout instead - shorter, better, more durable.

[the__alchemist]

Uncle Bob's rules: IMO do the opposite of what they say. They're a reasonable set if negated!

[pphysch]

> big brained developers are many, and some not expected to like this, make sour face