It's common advice in programming circles to prefer long functions like this because someone finds it easier to read.
My problem with it is when I need to make a change. I need to write a test first. And the pre-conditions for running this code include the banana, the gorilla, and half the observable universe.
I should qualify that and say *easier to read than several small functions scattered all over the place*.
Yes, indirection isn't abstraction and hiding control flow in highly procedural code is super annoying.
So is having to maintain highly procedural code by not being able to write tests for it and make changes swiftly and concisely.
There's a balance to be struck. The first step is to avoid stringing together code into a single function that updates the state of more than one thing or needs a ton of state set up before you can run it.
Breaking problems down into manageable sizes is a good thing.
@agentultra For me, the goal is to be able to divide code up into functions with names that (hopefully) explain obviously what they're doing. So someone reading it would think "I don't need to dive into that, because it's clear what it's doing"
Imo writing your code as a big long procedural recipe just means you didn't make an effort to factor it nicely.
Woke Leftist Trash
Luke Seale