Good practice for this two scenario

[vittorioc98]

hello guys!
I would like to know your opinion about what is better (or good practice) for these 2 samples below:

1) Is it better to make menu option as function or not?

with function

int main(int argc, char const *argv[])
{
    main_menu();

    ...

    return 0;
}

void main_menu(){
    printf("menu\n");
    printf("1) ...\n");
    ....
}

or just like this?

int main(int argc, char const *argv[])
{
    printf("menu\n");
    printf("1) ...\n");


    ...

    return 0;
}

The second sample is almost like the one above but for closing the application

void foo();
void bar();
void exit_app();

int main(int argc, char const *argv[])
{

    foo();
    bar();

    ...

    return 0;
}

void foo(){
    
    ....
    //if something went wrong
    exit_app();
}

void bar(){
    
    ....
    //if something went wrong
    exit_app();
}

void exit_app(){
    printf("Closing\n");
    exit(EXIT_FAILURE);
    ....
}

or like this?

void foo();
void bar();
void exit_app();

int main(int argc, char const *argv[])
{

    foo();
    bar();

    ...

    return 0;
}

void foo(){
    
    ....
    //if something went wrong
    exit(EXIT_FAILURE);
}

void bar(){
    
    ....
    //if something went wrong
    exit(EXIT_FAILURE);
}

i hope you don't look this like a stupid question.. i just want to improve my code readability and organization. Thank you all in advice

[Ganado]

Yes, separating out the part of the code that displays the menu (or does some other particular thing) into a function is a good idea, and can help with code organization (and code re-use). Your first function is good (but neither way is wrong).

For your second example... in C++ the use of exit() is not recommended, because it abruptly kills the program without doing any cleanup. C++ has a powerful feature called the destructor, which won't be properly run after a call to exit. The program's flow should be changed to end in main() and return from main instead. exit() (or terminate) should be reserved for scenarios like, "crap, something is totally wrong and I have no idea how I got into this situation or how to recover from it. Better to just kill the program at this point." [also consider throwing an exception instead of calling exit].

But that particular issue aside, I don't see a problem with it. If you are going to be calling a function multiple times, and want to give it a shorter name because it's used more often, then sure that's very appropriate.

[jonnin]

I will even go so far as to say that exit()/terminate() and so on should be reserved for specialty uses only. For example if you have hardware that your software can damage, a full stop may be the way to go. But for typical programs, I would say the following is usually true... if you can detect a problem and call exit() then you can also detect the problem and unwind back to main to call return(0) after logging/alerting/etc the problem. Getting back to main and exiting (zero or not) is preferred, in that case. Exit failure code is about worthless. If you are going to use the return codes, define them so the user can tell what went wrong, eg define 1 means not enough command line args, 2 means could not open some file, whatever... and return the one that makes sense (or if you want to get really fancy, use powers of 2 and 'or' multiple problems together).