"Clean Code" has garnered a bit of notoriety despite coining an endearing term we use in coding conversations. This book from 2008 is a compilation of principles and studies that "Uncle Bob" (a.k.a Robert Martin) had developed in his decades of programming. Many have incorporated his practices into their work, some swearing by it, and…

Lobsters is a community-driven platform for sharing and discussing links to articles, tutorials, and projects related to technology and programming. Readers can learn about a wide range of topics, from software development and system administration to cybersecurity and artificial intelligence. With user submissions, comments, and voting, Lobsters provides a platform for collaborative learning and knowledge sharing among technology enthusiasts.

Lobsters

An article discussing the flaws in Uncle Bob's approach to refactoring code and his implementation of his own principles. The author suggests that readers should come up with their own refactorings and take Uncle Bob's principles with a grain of salt.

Don’t Refactor Like Uncle Bob. Please

“Most programmers would rather deviate a little in abstraction, than to fragment a simple function into a stateful, side-effect-ridden tree of methods.” - THIS!

I can’t talk about refactoring, although the author makes a clear point here. But I’ve had fellow “senior” developers delete my comments from the code, quoting the “Clean Code” mantra that code needs to be self-commenting so you don’t need comments! The funny thing is, the same developers could not write self-commenting code. So yes, this book has done some damage already.

Reading Clean Code was a requirement in a few places I knew. Heck, in one of 'em, CTO would ask random questions about the content. I guess you can tell how this translated to the code quality.
I feel the more people talk about coding standards, chasing the “pure code” rabbit, the more they forgot what it really has to do. Customers won’t pay for five hundred side-effects-free methods, if they don’t deliver what they have to. New team members won’t comprehend the codebase that has abstractions on top of abstractions, because eventually they will lose track of “what leads where”.
“Good standards” in code is not having everything as pristine and by-the-book as possible, but having it readable and maintainable.

I’m enjoying his book, but heck, i guess in the end you still have to think for yourself.

Top marks to the author of this one. It was a well thought out and balanced critique. Even if you don’t agree (I do align with it for the most part) it’s a good one to see the other side of things.