multi-file programs - main.c recommended?

[G Patel]

Can anways explain why many multi-file programs I've seen don't have a
main.c file, instead main() is hidden in a file with a different name?
Is this just a preference, or is there an unspoken rule (or advantage).

I've been calling the file with main, main.c, and I was wondering if
there are any caveats against this (that might prevent me from being
laughed at or something).

 

[G Patel]

Can anways explain why many multi-file programs I've seen don't have

a
^^^
anyone

 

[Jens.Toerring]

Can anways explain why many multi-file programs I've seen don't have a
main.c file, instead main() is hidden in a file with a different name?
Is this just a preference, or is there an unspoken rule (or advantage).

I've been calling the file with main, main.c, and I was wondering if
there are any caveats against this (that might prevent me from being
laughed at or something).

There' nothing that would force you to call the file with the main()
function main.c - but there's also nothing that would keep you from
doing that. Personally, I prefer to give the file with main() a name
that reflects the one of the final program since I feel that this is
somehow the most logial choice (probably due to having started with
FORTRAN where the equivalent of main() was a function with the name
of the final program (IIRC) and it thus was natural to name the file
accordingly), but if you feel differently do it as you like and no-
one is going to laugh;-) With tools like grep it is simple to find
out where main() is, so there's no reason to worry.

Regards, Jens

 

[Rouben Rostamian]

Can anways explain why many multi-file programs I've seen don't have a
main.c file, instead main() is hidden in a file with a different name?
Is this just a preference, or is there an unspoken rule (or advantage).

I've been calling the file with main, main.c, and I was wondering if
there are any caveats against this (that might prevent me from being
laughed at or something).

There is no rule for/against this; you may call that file main.c
if you like.

If I were writing a program to play the game of solitaire,
chances are that the file that contained main() would be
called solitaire.c.

Strangely enough, if I were writing a program to play chess,
chances are that the file that contained main() would be
called main.c. There is no particular logic behind this.
It's a matter of whim/style.

 

[Keith Thompson]

Can anways explain why many multi-file programs I've seen don't have a
main.c file, instead main() is hidden in a file with a different name?
Is this just a preference, or is there an unspoken rule (or advantage).

I've been calling the file with main, main.c, and I was wondering if
there are any caveats against this (that might prevent me from being
laughed at or something).

If you have a software package that generates multiple executables,
you might have multiple files containing a main() function. In such a
case, it probably makes sense for each such source file to have a name
reflecting the name of the executable. (Or you can put them in
separate directories and call each one "main.c".)

There's no universal convention, and the C language doesn't care.

 

[Harshal]

there are many which have main.c , try google for MLAPM (used in n-body
simulations)

 

[Parahat Melayev]

Can anways explain why many multi-file programs I've seen don't have a
main.c file, instead main() is hidden in a file with a different name?
Is this just a preference, or is there an unspoken rule (or advantage).

I've been calling the file with main, main.c, and I was wondering if
there are any caveats against this (that might prevent me from being
laughed at or something).

I always use
$ grep -n main\( *.c
to find main if there is no main.c or [PROGRAMNAME].c

 

[Alan Balmer]

Can anways explain why many multi-file programs I've seen don't have a
main.c file, instead main() is hidden in a file with a different name?
Is this just a preference, or is there an unspoken rule (or advantage).

I've been calling the file with main, main.c, and I was wondering if
there are any caveats against this (that might prevent me from being
laughed at or something).

Normally, you would put the main() in a file which has a name
appropriate for your program. For example, if your program is going to
be called widget, put the main in widget.c.

Consider - if I always put main() in a file named main.c, after 20
years of C programming, I would now have a thousand files named
main.c! How would I remember which was which?

 

[Kiru Sengal]

Normally, you would put the main() in a file which has a name
appropriate for your program. For example, if your program is going to
be called widget, put the main in widget.c.

Consider - if I always put main() in a file named main.c, after 20
years of C programming, I would now have a thousand files named
main.c! How would I remember which was which?

You shouldn't have to 'remember.'


.../[Program 1 name]/main.c
.../[Program 2 name]/main.c
.../[Program 3 name]/main.c
.../[Program 4 name]/main.c
.
.
.
.../[Program n-1 name]/main.c
.../[Program n name]/main.c


Even though I rarely use 'main.c' myself, doing so shouldn't limit
someone's ability to 'remember'(recognize) the the program it belongs
to. Keith also stated a case where 'main.c' should be avoided, but I
don't think that applies here.

 

[Keith Thompson]

Normally, you would put the main() in a file which has a name
appropriate for your program. For example, if your program is going to
be called widget, put the main in widget.c.

Consider - if I always put main() in a file named main.c, after 20
years of C programming, I would now have a thousand files named
main.c! How would I remember which was which?

Presumably you wouldn't have to remember; you could tell by the name
of the directory it's in. (This assumes a programming environment
that keeps source files in directories, of course.)

I'm not saying you *should* call it main.c, only suggesting that doing
so doesn't necessarily mean you should be laughed at.

I consider either "widget.c" or "main.c" to be a reasonable name for
the source file containing the main program for "widget". The name
"main.c" could cause problems if a single project has multiple main
programs, but you can always put them in separate subdirectories.

 

[Alan Balmer]

Presumably you wouldn't have to remember; you could tell by the name
of the directory it's in. (This assumes a programming environment
that keeps source files in directories, of course.)

If your programming career is sufficiently short, simple, and
concentrated in one environment, that will work. More or less.

I'm not saying you *should* call it main.c, only suggesting that doing
so doesn't necessarily mean you should be laughed at.

I consider either "widget.c" or "main.c" to be a reasonable name for
the source file containing the main program for "widget". The name
"main.c" could cause problems if a single project has multiple main
programs, but you can always put them in separate subdirectories.

Hmm... That would mean the project I'm on now would have 432
directories. They could, of course, be organized as subdirectories
under the current set of directories, and I'm sure we could eventually
figure out how to get the makefiles to work again ...

Maybe next year.

 

[Eric Sosman]

Normally, you would put the main() in a file which has a name
appropriate for your program. For example, if your program is going to
be called widget, put the main in widget.c.

Consider - if I always put main() in a file named main.c, after 20
years of C programming, I would now have a thousand files named
main.c! How would I remember which was which?

"There is nothing like a main()!
Nothing in the world!"