It's probably time to stop recommending Clean Code

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.<p>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&#x27;t find them all that meaningful.

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&#x27;s still bad! So, I&#x27;m not that great of a programmer.<p>:-)<p>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: <i>make it easy to read and follow</i>. Especially since the client was buying the source code.<p>It was really freeing. I didn’t need to care about all the industry &quot;standards&quot;. By presenting it as &quot;easy to read&quot; 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 &quot;const&quot; to everything and that was probably proper.<p>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&#x27;t apply to the domain you are modeling.<p>If I was to instruct a young programmer today, I would steer them more towards being &quot;simple&quot; and less towards &quot;impressive&quot;. Being impressive and clever has its place. Too much, however, and no one will know what you were doing.

I spend so much of my time doing an invisible facepalm over dogma that developers believe, but can&#x27;t ever justify <i>why</i>. It&#x27;s always stuff that <i>sounds</i> sensible, but the lack of nuance makes them so destructive in practise. Whether it&#x27;s &quot;I try not to make my classes go over 250 lines&quot;, &quot;make a function do exactly one thing well&quot; (<i>nothing</i> does only one thing! bonus points for mentioning the &quot;unix philosophy&quot;), &quot;functions with a cyclomatic complexity over x should be split up&quot; (thanks, you&#x27;ve just made my analysis of this code n^2 times harder).<p>Meanwhile I count the days go by as people fight with linters and otherwise muddy git history trying to achieve an &quot;A&quot; &quot;code quality&quot; score. It&#x27;s amazing people are paid to do this.

A lot of Robert C Martins pieces are just variations on his strong belief that ill-defined concepts like &quot;craftsmanship&quot; and &quot;clean code&quot; (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&#x27;re not a Real Programmer (tm).<p>I&#x27;m not the only one who is skeptical of this toxic, holier-than-thou and dangerous attitude.<p>Removing braces from if statements is a great example of another dangerous thing he advocates for no justifiable reason<p><a href="https:&#x2F;&#x2F;softwareengineering.stackexchange.com&#x2F;questions&#x2F;320247&#x2F;has-can-anyone-challenge-uncle-bob-on-his-love-of-removing-useless-braces&#x2F;320262" rel="nofollow">https:&#x2F;&#x2F;softwareengineering.stackexchange.com&#x2F;questions&#x2F;3202...</a><p>Which caused the big OSX&#x2F;iOS SSL bug in 2014, see <a href="https:&#x2F;&#x2F;www.imperialviolet.org&#x2F;2014&#x2F;02&#x2F;22&#x2F;applebug.html" rel="nofollow">https:&#x2F;&#x2F;www.imperialviolet.org&#x2F;2014&#x2F;02&#x2F;22&#x2F;applebug.html</a><p>This link and thread on hackernews is good too<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15440848" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15440848</a><p>&gt;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). &gt; &gt;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. &gt; &gt;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&#x27;s when they applied, you know, science and statistic to safety. &gt; &gt;So, tools are upgraded: better color coded medicine boxes, for example, or checklists in surgery. But it&#x27;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. &gt; &gt;My take: give it a few more years, and software, too, probably will follow the same path. We needs more data, though.

&gt;Outside of a book, do we still read code from top to bottom?<p>This one I disagree with. We frequently read code in a browser, as part of a pull request or just exploring a repo.

Looking at the post, it seems the advise would be: &quot;Recommend clean code and leave it to the coder to interpret what clean code is.&quot;<p>I think it would still be a valuable advice compared to none at all.