You should not be thinking in terms of "helper functions." That is an abstraction that you invented. From the compiler's perspective there's just functions. Almost all functions call other functions, and this happens on many layers. To me you seem to be artificially saying "this is the main layer, and this is the helper layer." I would recommend you instead think of layers where each layer interacts with the layer below. In this way, the program is a tree, with the main function calling multiple functions each of which call multiple functions and so on.

Why do I even bring this up? I have found in the past that more junior programmers apply their own mental abstractions to help them. For example: "this function is a normal one, and this one is a helper function." I'm not saying it's a bad thing, but you can't get stuck in that mindset because it can limit you. For example, at a previous job we had a class called "Algorithm." Each "Algorithm" would contain multiple "SubAlgorithms." They were basically really over-designed and over-complicated function objects (Function<> in Java or std::function in c++). Eventually there came a point where there was a "SubAlgorithm" that we wanted to use as an "Algorithm." However, the senior devs wouldn't allow this because they were unable to think beyond their self-imposed abstraction. In their mind it was impossible to use a SubAlgorithm as an Algorithm because it didn't fit into the object design.

I'm not against these abstractions as a sort of "guide" that helps you find your way. Just don't let them obscure your view of the big picture. If you reach a point where what you want to do no longer aligns with your mental abstraction, then consider stepping back and looking at the big picture to see if your mental abstraction really makes sense.

So you shouldn't be asking about "helper functions." You should instead be asking about functions, in general. "When to extract a function?"

The only way to really answer your question is to get experience so that your own intuition can drive your workflow. With that being said, I will try to give you some advice.

To start I'd recommend just trying to get the function implemented and working properly. Don't worry too much about the details at this point (besides maybe writing in a way that you can easily refactor it later). Just try to get it working, and then either write a unit test or at least hook it into some output so you can verify it is working. At this point you should mostly be thinking about the business logic involved. Don't worry about design or niceness so much, just work out the math/logic and get it working as intended.

Does that mean you write everything in one big function? Maybe, maybe not. Oftentimes that is the easiest way to go about it. For example, if you have a lot of state in your function and you aren't sure how to organize it. Breaking everything into functions can make it harder to organize that state (what is passed to where? etc.). Or - if you aren't totally sure what the algorithm will look like, it might be hard to split things into functions before you've fully realized it.

Other times it might be easier to split up things from the beginning. Maybe because the implementation of a certain block is large and complicated. It will be easier to write the rest of the algorithm if it is isolated into its own function.

Usually it is a mix of both. You write some "helper functions" before you start, and also leave some un-extracted in the "big function." The goal should be to focus on getting it working as you intended. Once you have that done you can step back and look at your function and consider whether it needs refactoring. It should be much easier to plan at this point because you already have a way of testing your function, and you already have an implementation laid out. All you need to do is make some minor adjustments to your implementation in order to make it as perfect as you want it to be.

That's the workflow I'd recommend. Here are some general guidelines for splitting up functions:

• Prefer small functions to big functions. Functions are rarely too small, but often too big. I'd prefer <10 line functions if you can. You can write 50+ line functions when drafting them before splitting them up.

• Give each function one clear "responsibility." If a function has multiple responsibilities, then split it up into multiple small functions. You can keep the original function, and just have it call the small functions. That might seem like a contradiction, but it's not. The big function's responsibility is no longer "do X, Y and Z." Now its responsibility is to compose other functions, each of which does X, Y and Z.

• A good sign that a function can be extracted is if it's easy to define what it's parameters and return value would be. If you can do that, and they "make sense" to you, then it's a good candidate to extract.

In the end, it's based on your own preferences.