I would say that if your program looks like this, you've gone too far:
Code:
#include <stdio.h>
void print_hello_world(void)
{
printf("Hello, world!\n");
}
int main(void)
{
print_hello_world();
return 0;
}
One way that I sometimes think about my main function is, if I had to describe only the highest-level tasks for my program, like I was giving a 1 minute summary to somebody.
Never concern yourself with the efficiency of your program until you have incontrovertible proof that it is too slow. Even when you know it's too slow, function call overhead is so tiny, it's hardly going to make a difference in most cases; best to look at ways to improve your algorithms, which often gives huge speed ups. Besides, if you really need to avoid function call overhead (say, for a function called in a really tight loop that gets run millions or billions of times), you should use the inline keyword, which allows you to have the organizational benefits of functions without the function call overhead (note, as with most things, there is a trade-off).
I rarely see functions used too much, it's far more common to see not enough use of funcitons. Any time you find yourself re-writing what is essentially the same piece of code you have elsewhere in your program, you should put it in a function. I also use "one screenful" of code as a rough guideline for how long a function should be (note, screenful for me is 70ish lines). There's also the idea of
cyclomatic complexity, as a way to gauge when your functions have become too big.
Processes is probably the wrong word here, usually in computer speak, that refers to an instance of a running program. If you mean one function with lots of logic doing lots of things, versus several small functions, each doing their own thing, then the answer is several small functions. Refer again to cyclomatic complexity. A function should do one thing and do it well. That way it's easy to design, code, test and maintain. It also facilitates reuse, via separation of concerns, i.e. keeping your code loosely coupled, so changes to A don't automatically break B.
Experience is one of the best teachers. Write, rewrite and maintain your programs, trying new designs and fixing problems with your old design. Always analyze what you do, ask yourself how your structure and breakdown of work into functions facilitates or hinders updating and maintaining your code. Read bad code to learn what not to do. Read good code to learn what you should do. Ask experts for their opinion on your code and how they might improve it.
