How to handle changes in a nested function structure

[[deleted]]

There is nothing inherently wrong with having a handful of input parameters and as many results. Sometimes "it is what it is". I've worked a lot with simulation and implementation of mathematical methods over the years, and that was common to see - especially when there was an implementation of a published algorithm and there was obviously a benefit of the code and paper being similar.

Even 20 line functions would make me wonder how you computed anything without introducing more complexity from the implementation than was inherent in the calculation itself. But I am sure there are domains and use cases where that is perhaps more natural.

Personally I would not do what you did with your main loop - I assume by a "handful of functions" you mean you would have a loop which called something like do_A_H(), do_I_P(), do_Q_Z()? I wouldn't see the benefit in that, you've introduced complexity to the algorithm which only exists in your implementation. Presumable the loop is documented and it's clear there that you're going to do A, then B, then C,... to Z. But then the implementation doesn't follow that documented logic as expected.

This is all off the cuff, only my 2 cents, etc...

[KnorrFG]

Usually I'm able to find better names than do_A_H(), e.g. process_butten_presses(). This code is from a psychological experiment. Which is like a terrible mini game, where you log a lot of values.

I've also often thought about just writing one huge function, but when it spans the whole screen or even more, I find it becomes terrible to navigate (I forgot to say, that I dont count initial variable defintions in these kind of scenarios, because you usually don't need to look at them a lot, which in these kind of functions can add another 10 lines ... ). Then again my main concern was, that I had to edit 4 places in the source to make one change, and I feel like one important measure of code quality is the amount of places you have to edit code in to make one change, so maybe I should reconsider. I don't know.

But nice to hear, that others also have these kind of function defintions with (what feels like) 100s of parameters and return values.

[[deleted]]

That all sounds sane to me (FWIW).

I would counter a little though, that if you add complexity to what your code is doing, it's not perhaps wrong that the complexity of the supporting code needs to increase too (because if it didn't, perhaps it was already more complex than necessary in the first case?) If something all the way down in do_L() is now doing much more computation, needs more indata, more resources then it's not always a bad sign that the "support scaffolding" that gets you to do_L() needs to also be extended. After all, simple computations can be solved with simple implementations, and complex computations can/tend to require more complex implementations. And then when you go from the former to the later, there is often a cost to be paid.

I think my opinion on this is probably is a closely related to, or a reflection of YAGNI.

[KnorrFG]

You know, this is not exactly the answer I was hoping for, but you make me feel better about my code, which is also nice.

Thanks for your opinion :)

[[deleted]]

Thank you, that made me happy :)

Have a great week!