It's probably time to stop recommending Clean Code @ Things Of Interest
It makes me sad to see people upvote this.
Robert Martin's "Clean Code" is an incredibly useful book which helps write code that Fits In Your Head, and, so far, is the closest to making your code look like instructions for an AI instead of random incantations directed at an elder being.
The principle that the author of this article argues against seems to be the very principle which helps abstract away the logic which is not necessary to understand the method.
public void calculateCommissions() {
calculateDefaultCommissions();
if(hasExtraCommissions()) {
calculateExtraCommissions();
}
}
Tells me all I need to know about how what the method does. It doesn't matter if there's 30 private methods inside the class because I don't read the whole class top to bottom.
Instead, I may he interested in how exactly the extra commissions are calculated, in which case I will go one level down, to the calculateExtraCommissions() method.
From a decade of experience I can say that applying clean code principles results in code which is easier to work with and more robust.
@dandi8 @JackbyDev Most of the criticism in the article talks about side-effects using a far stricter (and imo more useful) definition than Martin did.
I tend to agree, and would avoid both side-effects and writing code like Martin. However this book targets the mainstream, and afaik the mainstream hasn't yet accepted the new definition of side-effect.
Martin has since embraced FP more than the mainstream. So he's somehow both ahead of and behind the curve.
This is a good point. A perfect litmus test for this is whether people consider logging a side effect. With the strict, functional definition it is. With the loose, practical definition it is not.
Any examples of the claim that he’s embraced FP more?
Last I saw, he was making wild, baseless assertions about FP concepts like monoids and monads on Twitter.