So, that’s my question. Why use prototypes of functions? Isn’t it simpler to just put all functions over the main(), this increases the margin of error if nothing else.
It may seem like a good idea, but when you do this you are making your brain work backwards. Code is only supposed to flow one way: From top to bottom. When you start putting your other functions above main(), It’s like putting the fist step at the very end of a list, and while the code may still work, it could confuse you later on and it almost definitely will confuse anyone else who tries to read and troubleshoot your code.
There are two conflicting aspects to this.
In the original C Language, it is required that anything used from within the program file must be declared first (whether in an #include or in the same file).
On the other hand, it is desirable to do progressive disclosure and expand from the top down as Donald remarks.
Declaring prototypes up front satisfies the original C Language constraint, and putting the actual definitions below the top level function (main() in this case) satisfies the idea of looking below the point of use for details.
I think that is good practice here because it does go with the use of the GDD and the idea of pseudo-coding at the top, then refining details in the subordinate functions, and their subordinate functions, etc.
When writing programs, one can probably do it either way, because you know your way around. For reading the program, it is useful to see the top-level structures first and then check into the subordinate functions knowing the context of their use. I find that useful even when returning to old code of my own. I can refresh my understanding if the subordinate function definitions follow those of functions that rely on them.
At some point, we’ll be using multiple files as part of a single project and there will only be the prototypes (possibly via #include files) for functions defined in separate files. There is a lot of art and craftsmanship involved and tastes differ.