views:

161

answers:

8

Just had a 'Fundamentals of Programming' lecture at uni and was told that the convention for using/declaring functions is to have the main() function at the top of the program, with functions/procedures below it and to use forward declarations to prevent compiler errors.

However, I've always done it the other way - functions at top main() at bottom and not using forward declarations and don't think I've ever seen it otherwise.

Which is right? Or is it more a case of personal preference? Some clarification would be hugely appreciated.

+10  A: 

It's up to you. Personally, I keep main on bottom because the times when I have other functions in there, it's either just one or two other little functions or a code snippet.

In real code, you'd have hopefully split your project up (having multiple "unrelated" functions in a file is bad) and so main would likely be nearly alone in the file. You'd just #include the things main needs to get things going and use them.

GMan
I'd do the same. I've never seen a file with main on top. It just adds work if you forward declare and then implement once you change something. Also like the part of splitting your code up!
Mario The Spoon
+1 for the suggestion to have `main` alone in its file.
Kristopher Johnson
A: 

The advice to have declarations (function prototypes) is more related to C then to C++, because in C++ there are no implicit function declarations, so you must always declare before use. Therefore you will definitely have at least one function declaration which is not definition if you have a recursion involving more then one function.

For a small project use whatever style you want but be consistent. For a large project you'll probably need several .cpp files and have the interfaces (be they classes or functions) defined in the header files. Also be consistent at least within a single file.

And the last thing, have I said to be consistent?

vitaut
Not really true. Order matters, because, in C++, you must declare a function before it's used.
Bruno Brant
I mean that there are no hard rules to follow. Will rephrase.
vitaut
+4  A: 

There could be the case when your functions are related to each other. If you simply write them above the main() without forward-declaration you have to order them so they'll know the functions they depend on. In some cases (circular references) it won't even be possible to compile without forward declaration.

When forward declaring the functions you won't run into this issue.

Additionally when having main() as first function, you'll produce more readable code, but thats perhaps just personal preference.
It could also be more readable cause another coder has on overview about the functions he'll find in the file.

MOnsDaR
I agree that putting `main` first tends to make things more readable, but I've certainly seen counterexamples. Ideally, someone reading the code can do so from top-to-bottom, and should get an overview of what's going on at the top and then delve into details, so `main` on top is a natural way to achieve that.
Kristopher Johnson
+3  A: 

If there is a standard, it's to have the function declarations in a .h file which is included. That way, it doesn't matter what the order of functions in the file is. I almost never write functions without a declaration, and it takes me aback when other people do.

David Thornley
+2  A: 

This approach is most likely favoured by your professor and most likely the reason she's teaching it as convention. There are two options here, go with the flow (i.e. don't try to disrupt and potentially get marked down for stuff because your professor feels that you're not following "convention") or explain to her - there is no requirement to do it this way (or any other way), as long as the intention of the code is clear!

Nim
A: 

I normally use the second form because you have to maintain function declarations - they must have the right signature and name, and imo, they're just excessive typing when you could just define the functions first. No maintenance, no wasted time.

DeadMG
+3  A: 

The standard most professional C++ developers use is this.

  • two files per class: the header file (named e.g., Class.h), which only declares all of the class' data members and functions; and the implementation file (named Class.cpp in the same example), containing only implementations of those functions.
  • the main function (if your solution has it) goes into a file named, e.g. Main.cpp all by itself.

It is OK to put multiple classes or even the entire program into one file when you work on small-scale home or school projects. Because of the small scale, it doesn't really matter how you order the classes or the functions. You can do what is more convenient to you. But if your professor requires students to follow certain code standards for homework (e.g. put main() first), then you have to follow those standards.

azheglov
I'm of the same idea that azheglov, there should be two kinds of files, declaration (xx.h) and implementation (xx.cpp), also logically the code should be organized by means of namespaces, each one containing related classes. The order of functions is not requisite for new compilers, old compilers required to declare functions before being used. I prefer more public and simplest first, then more private and most complex.
ArceBrito
As much as you want to follow your own coding style, you might as well start getting used to following one that's laid down by someone else. Once you're out in the workforce, you'll find that your company will have set up a coding standard to which you are expected to adhere when writing code for them. Usually, company coding styles are put in place to make at least the formatting of the code appear as uniform as possible from one programmer to the next, because people often have to go into each other's code for one reason or another.
RobH
A: 

I think the principle that applies here is "Don't Repeat Yourself". If you use a forward declaration, you're repeating yourself unnecessarily.

Rob K
FWIW, I don't think DRY applies to issues like this. C++ just naturally requires a lot of redundancy, and structuring your code in an unnatural way to try to reduce it is not a good idea.
Kristopher Johnson
I disagree that it's an unnatural way. It's perfectly natural to me. I've done it that way for years, and I do it that way in every language I program in. I've found the specific case given in the original question results in useless book keeping. And I don't see why you think C++ requires a lot of redundancy. I've found C++ allows me to eliminate redundancy as much as any language.
Rob K