Robert Martin’s “Clean Code” is an incredibly useful book which helps write code that Fits In Your Head
It has the exact opposite effect. It leads to code that doesn’t fit in your head.
Because his style of coding leads to code where everything useful are 10 levels deep in nested method calls. If I want to understand how the code works and how my changes will affect the overall picture, I need to keep a dozen methods in my head and how all of these are connected to each other.
And he’s mostly working with global states, so knowing where variables are assigned is just a huge pain.
So many times I’ve looked into code like this where I finally find what I’m looking for, only to forget how I even reached this part of the code. So I need to backtrack to remember how I got there, but then I forget where that damn thing I was looking for is. And I go back and forth until I figure out a mental model of the code. It’s awful!
Compare that with just having one big method. Everything is in front of me. I don’t need to keep that many things in my head at the same time, because everything I need is right there in front of my eyes.
Sure, sometimes breaking out to separate methods can make it easier to communicate what the code does and the boundaries of each scope, but if it’s overdone it leads to code that’s impossible to work with.
I heavily disagree it’s easier to write good code if you follow clean code. Especially if you follow his examples throughout the book. Most of his examples are just over engineered messes held together by side effects (even if he says side effects is a bad thing).
If he can’t write good code by following clean code, why should you? He even picked the examples himself and failed!
It has the exact opposite effect. It leads to code that doesn’t fit in your head.
Because his style of coding leads to code where everything useful are 10 levels deep in nested method calls. If I want to understand how the code works and how my changes will affect the overall picture, I need to keep a dozen methods in my head and how all of these are connected to each other.
And he’s mostly working with global states, so knowing where variables are assigned is just a huge pain.
So many times I’ve looked into code like this where I finally find what I’m looking for, only to forget how I even reached this part of the code. So I need to backtrack to remember how I got there, but then I forget where that damn thing I was looking for is. And I go back and forth until I figure out a mental model of the code. It’s awful!
Compare that with just having one big method. Everything is in front of me. I don’t need to keep that many things in my head at the same time, because everything I need is right there in front of my eyes.
Sure, sometimes breaking out to separate methods can make it easier to communicate what the code does and the boundaries of each scope, but if it’s overdone it leads to code that’s impossible to work with.
Clean code does not prevent writing bad code, it just makes it a bit easier to write good code.
OF COURSE you can follow the principles and still write bad code, because so much more goes into it, including skill.
A giant method with everything laid out, potentially mixing abstractions sounds like a nightmare to me. It leads to cognitive overload.
I heavily disagree it’s easier to write good code if you follow clean code. Especially if you follow his examples throughout the book. Most of his examples are just over engineered messes held together by side effects (even if he says side effects is a bad thing).
If he can’t write good code by following clean code, why should you? He even picked the examples himself and failed!