No, it isn't
Programming
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
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
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 what the method does - it calculates default commissions, and, if there are extra commissions, it calculates those, too. 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 be 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.
Edit:
To be clear, I am not condoning the use of global state that is present in some examples in the book, or even speaking of the objective quality of some of the examples. However, the author of the article is throwing a very valuable baby with the bathwater, as the actual advice given in the book is great.
I suppose that is par for the course, though, as the aforementioned author seems to disagree with the usefulness of TDD, claiming it's not always possible...
If those functions are huge units of work or pretty complex, I can agree. For most cases though, a simple code comment should do to explain what's going on?
@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.