Thread: source style recommendations: in search of...

Well, if you're working on any real-sized project, you're just gonna have lots of files. However, usually, you'll be working with only a handful of them at a time because that's where your attention is focused. I mean, for example, once your disk I/O routines are done, you almost never have to open that file again.

Also, If you have any kind of decent compiler, you should have a popup menu at the top you can click and it lists the functions in the file your in. Otherwise, you should _know_ what files your functions are in.

Perhaps this will help--

I tend to break project files this way--

consts.h - holds all constants
typedefs.h - holds all special typedefs/defines/enums
chrono.h - project history documention (not included in project)
main.c/h - main() and event type stuff
menu.c/h - menu bar management
filei/o.ch - generic file i/o routines
core.c/h - whatever project is really about
...
and so on

I break files up by functionality. Now that you don't have segment limitations you can put as many functions/procs in a sourcefile as you like.

enjoy.

Just some ideas:

If you can distinguish quite different tasks in your project, you could make subdirectories for each task (i.e. the interface code for a window or dialog box, the code for a computation thread, input/output functions for each filetype...). Usually you're focussing on one such a task at a time, so it won't make you switch directories a lot.
Some people like to put all .h-files and resource file in separate directories.
Most people programming C++ like to put only one class in each .C-file, and then call the .C-file identical to the class in the file. In plain C you can "emulate" C++ by "intelligent" use of static variables and functions.

Anyway: whatever you choose to do, it's never right in the eyes of other programmers .

greetinx,
alex