
It's probably time to stop recommending Clean Code - mumphster
https://qntm.org/clean
======
RoyalSloth
To be entirely honest, most of his books are pretty awful, as they are mostly
preaching something for the sake of preaching and selling the books. I bought
his last one (Clean Architecture) as I wanted to improve myself as an
architect, just to realize its riddled with fluff and rarely anything in there
is actionable advice. For some reason the reviews from his followers are
mostly glowing.

I also found myself agreeing with everything written in this blog post. For
the record I have read his famous Clean Code, Clean Coder and Clean
Architecture and I don't find them all that meaningful.

------
pcunite
I have code running in a product first put together in 2001 that is still in
operation today. It was rewritten in a different language shortly thereafter,
then refactored again sometime after that. I wrote it, and you know what? It's
still bad! So, I'm not that great of a programmer.

:-)

I had to sell a portion of the code a while back. Embarrassed for anyone to
see it, I tried to focus on just one thing: _make it easy to read and follow_.
Especially since the client was buying the source code.

It was really freeing. I didn’t need to care about all the industry
"standards". By presenting it as "easy to read" I could unburden myself of
intellectual contests. They do have merit and I appreciate those smarter than
myself. But for this situation, the client was at liberty to turn the code
into anything they wanted. My code must be the standard for readability and it
was fast enough. They added "const" to everything and that was probably
proper.

These manifestos are really just guide rails which without could otherwise
send you over cliffs. Guides are not laws and rules to be adhered to
literally. They are to make you think about why you have twenty levels of
inheritance, ten function parameters, and abstractions that don't apply to the
domain you are modeling.

If I was to instruct a young programmer today, I would steer them more towards
being "simple" and less towards "impressive". Being impressive and clever has
its place. Too much, however, and no one will know what you were doing.

~~~
jasonlhy
I would say many examples in the book is just for demo. In real life, it have
to trade off somethings

------
bedobi
A lot of Robert C Martins pieces are just variations on his strong belief that
ill-defined concepts like "craftsmanship" and "clean code" (which are
basically just whatever his opinions are on any given day) is how to reduce
defects and increase quality, not built-in safety and better tools, and if you
think built-in safety and better tools are desirable, you're not a Real
Programmer (tm).

I'm not the only one who is skeptical of this toxic, holier-than-thou and
dangerous attitude.

Removing braces from if statements is a great example of another dangerous
thing he advocates for no justifiable reason

[https://softwareengineering.stackexchange.com/questions/3202...](https://softwareengineering.stackexchange.com/questions/320247/has-
can-anyone-challenge-uncle-bob-on-his-love-of-removing-useless-braces/320262)

Which caused the big OSX/iOS SSL bug in 2014, see
[https://www.imperialviolet.org/2014/02/22/applebug.html](https://www.imperialviolet.org/2014/02/22/applebug.html)

This link and thread on hackernews is good too

[https://news.ycombinator.com/item?id=15440848](https://news.ycombinator.com/item?id=15440848)

>The current state of software safety discussion resembles the state of
medical safety discussion 2, 3 decades ago (yeah, software is really really
behind time). > >Back then, too, the thoughts on medical safety also were
divided into 2 schools: the professionalism and the process oriented. The
former school argues more or less what Uncle Bob argues: blame the damned and
* who made the mistakes; be more careful, damn it. > >But of course, that
stupidity fell out of favor. After all, when mistakes kill, people are serious
about it. After a while, serious people realize that blaming and clamoring for
care backfires big time. That's when they applied, you know, science and
statistic to safety. > >So, tools are upgraded: better color coded medicine
boxes, for example, or checklists in surgery. But it's more. They figured out
what trainings and processes provide high impacts and do them rigorously.
Nurses are taught (I am not kidding you) how to question doctors when weird
things happen; identity verification (ever notice why nurses ask your birthday
like a thousand times a day?) got extremely serious; etc. > >My take: give it
a few more years, and software, too, probably will follow the same path. We
needs more data, though.

------
ris
I spend so much of my time doing an invisible facepalm over dogma that
developers believe, but can't ever justify _why_. It's always stuff that
_sounds_ sensible, but the lack of nuance makes them so destructive in
practise. Whether it's "I try not to make my classes go over 250 lines", "make
a function do exactly one thing well" ( _nothing_ does only one thing! bonus
points for mentioning the "unix philosophy"), "functions with a cyclomatic
complexity over x should be split up" (thanks, you've just made my analysis of
this code n^2 times harder).

Meanwhile I count the days go by as people fight with linters and otherwise
muddy git history trying to achieve an "A" "code quality" score. It's amazing
people are paid to do this.

------
swaranga
>Outside of a book, do we still read code from top to bottom?

This one I disagree with. We frequently read code in a browser, as part of a
pull request or just exploring a repo.

------
ketanmaheshwari
Looking at the post, it seems the advise would be: "Recommend clean code and
leave it to the coder to interpret what clean code is."

I think it would still be a valuable advice compared to none at all.

~~~
jonnypotty
How is advise from someone who literally can't do the thing they're advocating
valuable? Because it confirms some old tired OOP tropes?

