Hi,
the main.c includes, like all the other .c files only headers for the stuff needed in the main.c file. All included .h files include their code and all other dependencies become resolved; the list of .c/.h files will be generated automatically by the construction I posted above. Maybe this answers also your other question. If you have for example a function A() in a.c and a function B() in b.c and A() calls B(), then you'll write #include b.h at the top of a.c, after #include "a.h". Even if B() calls A() as well, this imposes no problem: include a.h at the top of b.c after including b.h. In the end, a.h and b.h are included before a.c and b.c and everything is fine. So, include the header of the .c file first, then include all other headers that are required for the .c file, nothing more. If you need other .h files for types, globals, definitions, etc., include them as well, but always after including the header of the .c file. The only thing that belongs in .c files are functions.
You should also comment your functions carefully, you should write at least a brief (!) comment in the header what a function does. When you look up later function names, this is really helpful. What I prefer is to write the same brief comment to the function in the .c file as well, plus an extensive comment afterwards that explains to me what a function does, if it is complex. Sure, if that is an easy function, you can waive that, but sometimes you do really badass stuff and even some days later you wonder what you did there - and then you well appreciate a nice comment then.
How you document parameters and return values and so on is a matter of taste, you'll have to find your own way. What I prefer at the moment are prose comments that tell you how things work like you are talking with a person, like
// stores the object space position of a terrain entity vertex (defined via row & col) in
// 'p'. If p == NULL, a temporary vector will be returned. If row/col is outside the
// terrain entity, it will be clamped to the nearest border vertex
//
VECTOR* hmp_entgetvertex (ENTITY*, int row, int col, VECTOR* p);
or
// saves the deformation of a terrain entity back into the file it was loaded from. It
// only works for entities which were loaded from a physically existant .hmp file! It
// doesn't work for dynamically created terrain entities and entities, which were
// loaded from a WRS resource
//
BOOL hmp_entsave (ENTITY*);
Even if there is only one parameter like in the second case, functions can have several boundary conditions, default cases and whatelse, so it is very important to write it down.
Others prefer lists, one line for each parameter and one for the return value, like
// My function does...
//
// Param: int a blabla
// float b blabla
//
// Return: true/false upon success
which is also very popular, but for my personal taste it is wasting so much space, especially if the parameter list is long and if the description is long - because sometimes, parameters speak for themselves (e.g. by the type, or by the naming).
