145
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 10 Aug 2024
145 points (95.0% liked)
Programming
17314 readers
8 users here now
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
founded 1 year ago
MODERATORS
In which case you will discover that the calculateExtraCommissions() function also has the same nested functions and you eventually find six subfunctions that each calculate some fraction of the extra commission, all of which could have been condensed into three lines of code in the parent function.
Following the author's idea of clean code to the letter results in a thick and incomprehensible function soup.
It's only as incomprehensible as you make it.
If there are 6 subfunctions, that means there's 6 levels of abstraction (assuming the method extraction was not done blindly), which further suggests that maybe they should actually be part of a different class (or classes). Why would you be interested in 6 levels of abstraction at once?
But we're arguing hypotheticals here. Of course you can make the method implementations a complete mess, the book cannot guarantee that the person applying the principles used their brain, as well.
Because there aren't 6 interesting levels of abstraction. It's like talking to a child:
Because abstractions leak. Heck, abstractions are practically lies most of the time.
What's the most time-consuming thing in programming? Writing new features? No, that's easy. It's figuring out where a bug is in existing code.
How do abstractions help with that? Can you tell, from the symptoms, which "level of abstraction" contains the bug? Or do you need to read through all six (or however many) "levels", across multiple modules and functions, to find the error? Far more commonly, it's the latter.
And, arguably worse, program misbehavior is often due to unexpected interactions between components that appear to work in isolation. This means that there isn't a single "level of abstraction" at which the bug manifests, and also that no amount of unit testing would have prevented the bug.
I usually start from the lowest abstraction, where the stack trace points me and don't need to look at the rest, because my code is written well.
That's great, but surely, from time to time, you have to deal with code that other people have written?
I do, and whether I have a good time depends on whether they have written their code well, of which the book's suggestions are only one metric.
I hear you, but here's my experience:
I've had one coworker whose personal coding style actually somewhat resembled that in the Clean Code examples. He wrote functions as small as possible, used many layers of abstraction, and named everything very verbosely and explicitly.
Now, to be fair, I don't think he did that because of Clean Code, and he also didn't follow most of the good practices that Martin recommends. Most egregiously, he almost never tested things, even manually (!!). He once worked an entire weekend to finish something that I needed for my part of the project, and when he was done, it didn't work, because he hadn't actually run it at any point (!!!!!).
But even when his software did work, it was horrendous to navigate and modify, specifically because of that style of writing code. I know, because when he retired, I was the only person on the team who could deal with it, so his part of the project fell entirely on me.
Now, I've also had to work with code that had the opposite problem: short names, no abstraction. And a sort of "worst of both" codebase where the functions were exceedingly long and full of near-duplicate functionality, but overall there was a fair amount of modularity and abstraction.
But in my opinion, it was much harder to deal with the code that hid all of its weirdness behind layers and layers of abstractions, despite those abstractions being carefully documented and explicitly named.