Defining functions below int main() - Best practices?

Quote:

---

Originally Posted by Programmer_P

I don't understand why one would define some functions below int main()...???

What is the point of that exactly?

---

Readability. Most people are interested in reading main() first, so they get a general idea of what the program is doing. Defining functions before main is just laziness. You should declare them before main and then define them after main, and if you have more than 2-3 functions they should each be in separate files, which makes declaring them not only necessary, but it makes moving them faster if you already did it for the first several functions.

Quote:

---

It would seem to me that the best practice would be to have int main() at the bottom of all code. Why would you write code beneath the main() function?

---

No, having main at the bottom is not good, it makes the reader have to search for main, which is the place to start when analyzing code and it gets annoying. Sometimes for small programs, where you only have a couple functions other than main it can be more convenient to have a single source file. This generally is ok but at some point it becomes unwieldy. Having each function in a separate file, named after the function, allows you to quickly navigate to the function you need in most IDE's.

Quote:

---

Also, in a book entitled "Practical C++" by Robert W. McGregor, in example code, the main() function always has the return type void instead of int. Why is this? I thought the main function always has to be int? Or does it just depend on the compiler/platform?

---

There is nothing wrong with having a void return type. Windows and Linux generally prefer that you return int though. When coding for microcontrollers it is generally bad to return type int, as stack and ram space are at a premium and you should generally avoid frivolous reservations, like the space it takes to represent return 0 versus return. 4 bytes may not seem like much, unless you are dealing with 2k of ram.

Quote:

---

Originally Posted by slingerland3g

True, yet from time to time in analyzing code I do see separate header files for just declarations only, the modularity of such an implementation of header file madness I am not sure on.

---

I do not see how that is "header file madness"; it is typical for forward declarations to go into header files, and perhaps the necessary classes have already been defined.

Quote:

---

Originally Posted by abachler

There is nothing wrong with having a void return type. Windows and Linux generally prefer that you return int though. When coding for microcontrollers it is generally bad to return type int, as stack and ram space are at a premium and you should generally avoid frivolous reservations, like the space it takes to represent return 0 versus return. 4 bytes may not seem like much, unless you are dealing with 2k of ram.

---

This might actually point to a minor inconsistency in the C++ Standard: the wording is such that one can interpret the requirement for the global main function to return int as pertaining to freestanding environments as well, even though it is also clearly stated that "start-up and termination is implementation-defined".

Programmer_P;

Code:

---

int lolwat();

int main()
{
        lolwat();
        return 13;
}

int lolwat()
{
        // ... ten pages worth of code.
}

---

That just save you from having to scroll through ten pages of code to find main, when all you might want to do is see the program flow real fast (which becomes a frustrating ordeal when you have to scroll through ten pages of code to find main).

Obviously I exaggerated intentionally, since it usually requires blinding contrast to make subtle points clear.

*You might argue that it's less useful, but others would disagree. Should programming features be modified for you? Nah. That's why it's there, because some consider it useful, and some do not. All options satisfied! It really shouldn't need to be argued further, there's pros and cons to everything, and what applies is relative to purpose and context.