So I was coming here with my pitchfork to blabber about how code is written for humans and that it's important to be simple and clear and stuff... but then I realized this was a jab about that dumb book. Fuck that book.
As someone who regularly has to deal with code that has been broken needlessly into smaller functions so that I have to constantly jump around to figure out what is going on, this really resonates with me.
The latest case was someone who took something that really only needed to be a single function and instead turned it into a class with a dozen tiny methods.
"The cult of understandable things"
Yeah ok bro, sure.
Who doesn't like a gigantic shitty code that "just works" after all?
You have misunderstood. The is ranting against Clean Code, not clean code.
I think this author has some points, but this is attacking the wrong thing.
Clean code is not the source of the problems described. If you see similar code and try to extract a common abstraction without further consideration, congrats, you're thinking like a junior developer, and that's not Clean Code's fault, to pull one example.
The problem is that people recommend clean code to junior developers all the time. Clean Code is full of terrible advice and heuristics over critical thinking throughout, and is usually foisted on burgeoning juniors when they don't know any better.
In other words, you're correct that adherents of clean code are thinking like junior developers, because that's what clean code tells you to do.
That's not my observation. I could flip it around and accuse the author of defending massive if/else chains because my experience is that anything that needs more than a handful of lines of code is either a complex mapper or a nightmare of failed Boolean algebra.
That doesn't mean the bad code I've seen is OP's fault. It means there's a lot of shit programmers and adopting a particular style doesn't fix it.
Then you're just wrong. Clean Code directly tells you to make the mistakes the author of the article points out. The absurdity of the examples in the book should be evident enough.
You see two functions that look similar. Clean Code sirens start blaring in your head. You extract a common abstraction. You add parameters to handle the slight differences. Then more parameters. Then a config object. Then a strategy pattern because you're a Real Engineer™.
I’ve watched dozens of hours of Uncle Bob videos (not by choice) and this isn’t what he advocates. At all.
This author has no clue what they’re talking about.
This is an article by a person who doesn't understand SOLID principles, talking about programmers who don't understand SOLID principles.
Saw this, a long while ago:
https://www.youtube.com/watch?v=tD5NrevFtbU
It measures clean code to wreck performance to terrible degree.
From the looks of it, in Molly Rocket's view, clean code is an industry-wronging cult.
They've multiple videos on the subject, from different angles
https://www.youtube.com/results?search_query=molly+rocket+clean+code
Just putting this here for hopefully-more-accurate-view.
_ /\ _
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev