Is it good to use functions as much as possible?

Question

When I read open source codes (Linux C codes), I see a lot functions are used instead of performing all operations on the main(), for example:

int main(void ){
    function1();
    return 0;
}

void function() {
    // do something
    function2();
}

void function2(){
    function3();
    //do something
    function4();
}

void function3(){
    //do something
}
void function4(){
    //do something
}

Could you tell me what are the pros and cons of using functions as much as possible?

• easy to add/remove functions (or new operations)
• readability of the code
• source efficiency(?) as the variables in the functions will be destroyed (unless dynamic allocation is done)
• would the nested function slow the code flow?

Answer 1

Functions should help you structure your code. The basic idea is that when you identify some place in the code which does something that can be described in a coherent, self-contained way, you should think about putting it into a function.

Pros:

• Code reuse. If you do many times some sequence of operations, why don't you write it once, use it many times?
• Readability: it's much easier to understand strlen(st) than while (st[i++] != 0);
• Correctness: the code in the previous line is actually buggy. If it is scattered around, you may probably not even see this bug, and if you will fix it in one place, the bug will stay somewhere else. But given this code inside a function named strlen, you will know what it should do, and you can fix it once.
• Efficiency: sometimes, in certain situations, compilers may do a better job when compiling a code inside a function. You probably won't know it in advance, though.

Cons:

• Splitting a code into functions just because it is A Good Thing is not a good idea. If you find it hard to give the function a good name (in your mother language, not only in C) it is suspicious. doThisAndThat() is probably two functions, not one. part1() is simply wrong.
• Function call may cost you in execution time and stack memory. This is not as severe as it sounds, most of the time you should not care about it, but it's there.
• When abused, it may lead to many functions doing partial work and delegating other parts from here to there. too many arguments may impede readability too.

There are basically two types of functions: functions that do a sequence of operations (these are called "procedures" in some contexts), and functions that does some form of calculation. These two types are often mixed in a single function, but it helps to remember this distinction.

There is another distinction between kinds of functions: Those that keep state (like strtok), those that may have side effects (like printf), and those that are "pure" (like sin). Function like strtok are essentially a special kind of a different construct, called Object in Object Oriented Programming.

Answer 2

• Easy to add/remove functions (or new operations)

Definitely - it's also easy to see where does the context for an operation start/finish. It's much easier to see that way than by some arbitrary range of lines in the source.

• Readability of the code

You can overdo it. There are cases where having a function or not having it does not make a difference in linecount, but does in readability - and it depends on a person whether it's positive or not.

For example, if you did lots of set-bit operations, would you make:

some_variable = some_variable | (1 << bit_position)

a function? Would it help?

• Source efficiency(?) due to the variables in the functions being destroyed (unless dynamic allocation is done)

If the source is reasonable (as in, you're not reusing variable names past their real context), then it shouldn't matter. Compiler should know exactly where the value usage stops and where it can be ignored / destroyed.

• Would the nested function slow the code flow?

In some cases where address aliasing cannot be properly determined it could. But it shouldn't matter in practice in most programs. By the time it starts to matter, you're probably going to be going through your application with a profiler and spotting problematic hotspots anyway.

Compilers are quite good these days at inlining functions though. You can trust them to do at least a decent job at getting rid of all cases where calling overhead is comparable to function length itself. (and many other cases)

Answer 3

You should use functions that perform one logical task each, at a level of abstraction that makes the function of each function easy to logically verify. For instance:

void create_ui() {
    create_window();
    show_window();
}

void create_window() {
    create_border();
    create_menu_bar();
    create_body();
}

void create_menu_bar() {
    for(int i = 0; i < N_MENUS; i++) {
        create_menu(menus[i]);
    }
    assemble_menus();
}

void create_menu(arg) {
    ...
}

Now, as far as creating a UI is concerned, this isn't quite the way one would do it (you would probably want to pass in and return various components), but the logical structure is what I'm trying to emphasize. Break your task down into a few subtasks, and make each subtask its own function.

Don't try to avoid functions for optimization. If it's reasonable to do so, the compiler will inline them for you; if not, the overhead is still quite minimal. The gain in readability you get from this is a great deal more important than any speed you might get from putting everything in a monolithic function.

As for your title question, "as much as possible," no. Within reason, enough to see what each function does at a comfortable level of abstraction, no less and no more.

Answer 4

I guess I think of functions like legos. You have hundreds of small pieces that you can put together into a whole. As a result of all of those well designed generic, small pieces you can make anything. If you had a single lego that looked like an entire house you couldn't then use it to build a plane, or train. Similarly, one huge piece of code is not so useful.

Functions are your bricks that you use when you design your project. Well chosen separation of functionality into small, easily testable, self contained "functions" makes building and looking after your whole project easy. Their benefits WAYYYYYYY out-weigh any possible efficiency issues you may think are there.

To be honest, the art of coding any sizeable project is in how you break it down into smaller pieces, so functions are key to that.

Answer 5

This practice of using functions is really important as the amount of code you write increases. This practice of separating out to functions improves code hygiene and makes it easier to read. I read somewhere that there really is no point of code if it is only readable by you only (in some situations that is okay I'm assuming). If you want your code to live on, it must be maintainable and maintainability is one created by creating functions in the simplest sense possible. Also imagine where your code-base exceeds well over 100k lines. This is quite common and imagine having that all in the main function. That would be an absolute nightmare to maintain. Dividing the code into function helps create degrees of separability so many developers can work on different parts of the code-base. So basically short answer is yes, it is good to use functions when necessary.

Answer 6

One condition you can use: if part of the code will be reuse/rewritten, then put it in a function.