As many of you already know, I am a regular mentor on Dream.In.Code. With that I see common mistakes and design issues more than most people will probably ever seen in their full career. One design issue I would like to talk about today is the role of the main method and why it should be treated more like the conductor of an orchestra than 10 different band members. The main method should be directing your application and keeping the different parts working together by making gating its processes.
This method is important in some languages like C/C++, Java and even C# (especially when doing console apps). Unlike other functions it is usually the entry point to a program. It is the place where you begin your journey of designing your application. It may or may not take arguments from the command line and it may or may not return a successful value to the operating system. The one thing main should always do is direct activities in a program rather than trying to do all the activities on its own. It is the start of the application, not the application itself.
What do I mean by that? Well, all to often I see those new to programming try to stick all their program’s logic right into this single method. They try to show menus, collect user input, process that input, show other menus, run game loops or whatever all right in this “starting” method. They of course then run into a problem and since they only have this one method they don’t know where to start looking for the problem. What those new to programming need to understand is that the main method should contain the heart of the program and call out to various parts of the application to handle the individual tasks.
As an analogy the main method should be the conductor, or the person who directs an orchestra, and should not be the one running around trying to play all the instruments. In other words it should not be trying to show a menu or trying to collect input and process input and handling all the events and drawing stuff etc. It should be the method which calls a function to show a menu and when the menu is presented, it then calls another function to work on collecting the user’s menu choice. Once the choice is made, it should then give that choice to a function to handle the choice. We should not be seeing 100 line main methods or anything like that.
I think the main problem (no pun intended) is that when someone is being taught to create their first application they are asked to write a few lines in the main method. Maybe to print “Hello World” or to collect an integer and then do an addition on it only to display it right back out again. For those types of programs, great! Stick with what is simple. The problem arises when teachers or tutorials don’t stop at some point and say “Ok, we need to stop doing everything here in main and refactor all these duties out to other functions. No no, don’t show your menu here, put that menu in a function and call the function from main.”
I would argue that if you find yourself approaching 30 to 40 lines or more in main, you probably can start pushing out code to other functions. Other programmers might have a smaller or larger number of lines than that, but I find 30 a pretty good rounded number. Anything less than that and it is really not too unwieldy to handle and any more than that usually has a few lines that you can put into another function somewhere.
Well the problem isn’t just with the main method, it is the idea of knowing when to refactor code as a design practice. I am just bringing up the main method as the center of this blog topic because I often see beginners (and yes a few pros too sometimes) trying to do way too much in their main method. The real goal I think is to be able to look at your main method, at the end of your program’s completion, and get a summary of everything it is doing rather than seeing all the specifics. We should always strive to have functions do one thing and do it well. The main method is no exception to this rule.
Next time you start a program and have a blinking cursor inside main ask yourself this question… “Should main really know anything other than which functions to call and when?” If it knows about a variable to set the timing of a menu notice or how many panels are in a status bar then it might know too much and be doing more than one thing. When it comes to debugging it will also prove to be a nightmare to you, as well as us helping or maintaining your program, to find out exactly where the problem lies. Just keep your main method clean and orderly and we should have no problems!
Thanks for reading! 🙂
