Thread: How big should main() be?

Size of main() or any other function isn't that important. Complexity is.

If it is excessively difficult to read through a function and understand what it does, then that function is too complex. Yes, that is subjective, but simpler is better.

EVOEx's example is a case of making the function small, but making it meaningless. There is no point in having a one-line main() function, if that one line is so meaningless that it is necessary to dig through other source files to work out what that line does. [That is actually one common weakness of a lot of OO code, where lots of small functions delegate to other small functions, which makes it hard to follow what is happening].

Generally, one needs to follow a Goldilocks-style approach (not too big, not too small, just right) where "just right" means meaningful but not unnecessarily complex.

As a rule of thumb, try to minimise complexity of control structure in a program. Look carefully at every if() statement, loop construct, goto, thrown exception, etc to see if some way can be found to avoid doing it. If you have multiple distinct loop constructs, move each one into an (appropriately named) function of its own. If you have nested constructs (for example, nested for loops) consider moving the inner construct into a appropriately named function of its own. If your code tests a complex set of conditions, then write write a dedicated and self-contained function to do that test.

However, don't go overboard: the goal is understandable code, not small functions. If moving a nested for loop into a separate function makes the code harder to follow - or you can't come up with a suitably descriptive function name capturing what that inner loop does - then leave it as a nested loop.

Apart from being the entry point to a program, main() is nothing special - it is a function like any other. So it should be treated like any other function.

Originally Posted by phantomotap

If your girlfriend giggles, it is too small.

or too big

'main' doesn't deserve any special rules around how large it is. One can easily make main tiny by copying the entire contents of a huge main into a different function and then only calling that. However then you simply have a large function elsewhere with a different name.
Whatever is a good size for any other function is a good size for main also. Perhaps just no larger than the viewable height of a maximised window within the IDE.

Eh, manasij7479, if you did not notice, something went seriously wrong with your code formatting.

Yes, there seems to be a bug, when the code is pasted from a previous post.. \
(Had to manually put in whitespaces this time..perhaps the webmaster would be interested in this?)
Trying again:

Look at this:
This illustrates what I learnt a few months ago in face of the same dilemma.
A moderately large program(A Calculator , evaluating infix and rpn style input) is logically fit into the following main()

Code:

#include <iostream>
#include <string>
#include "token.h"
#include "rpn.h"
#include "shunt_y.h"
using namespace std;
int main()
{ 
    deque<token> dt;
    char q;
    string input;
    while(1)
    { 
         cout<<"Enter the expression:\n>"; 

         getline(cin,input); 

         dt = tokenize(input);  //tokenizes the input

         dt = infix_to_rpn(dt);  //converts it into rpn notation if it isn't already in 

         cout<<rpn_eval(dt)<<endl<<"Quit?\n>";   //Evaluates
         
         cin>>q;   //Loop Controls
         cin.ignore(numeric_limits<streamsize>::max(),'\n');
          if (q == 'y' )
              break;
         else continue;
   } 
   return 0;
}

Main should be rather small. It should be easy to read what your program does by reading main. It should not contain much logic, mostly showing program flow. But as others have said, don't make main a one liner.

Examples and small programs can have a large main, because dividing it into functions does not provide a significant amount of clarity, but this is not a good mold for larger programs.

I do not think that manasij7479 code is a good general example. Except for small projects, main shouldn't have direct calls to cin and cout. Here's a better version:

Code:

using namespace std;
int main()
{ 
    do { 
         string input = read_expression();
         deque<token> tokens = tokenize(input); 
         infix_to_rpn(tokens);
         double result = evaluate(tokens);
         print_result(result);
   } while( continue_prompt() );
   return 0;
}

Notice also how I don't need any comments.

On a similar note, I suggest the coding practice of writing main first, unless you need a test suit.

and actually read the expression in another function

Except for small projects, main shouldn't have direct calls to cin and cout

Could you explain the reasoning behind that ?..
I thought it(doing most,if not all io in main()) helped to make all the I/O transparent so that no extra interactivity is added inside the other functions..

Originally Posted by manasij7479

Could you explain the reasoning behind that ?..
I thought it(doing most,if not all io in main()) helped to make all the I/O transparent so that no extra interactivity is added inside the other functions..

It is good to separate IO from computation, but my code does that as well as yours. You don't need to put all the IO into main, you just need to have separate functions for computation and IO.

You want main to read like the program flow. Putting the details of how IO is done into main can interfere with that. In your example the IO of the loop control logic is not readable at a glance. Having a separate function for it with an easy interface changes that.