Multiple .c files

I am working on a 3D OpenGL GLUT game written in C using Xcode and I realised my main.c file was getting large. I had all these functions (e.g. GLUT keyboard support) that I would never edit, but still needed.

How would I go about splitting main.c into controls.c, graphics.c, sound.c etc etc. I tried doing this before, but It spat out a host of errors. Do I need to use header files?

Blacktiger Wrote:I don't think that you do, but a good best practice is to split your function declarations into header files and your function definitions into their own .c files to match the .h files.

That is correct; you don't have to use header files for your public function declarations but it very rarely makes sense not to.

@ mikey: Splitting up your code into multiple files is indeed a good idea to keep things more manageable. Yes you should use .h files to declare the functions that you want to share with other .c files (for lack of a better way to put it). Then you simply use either #include (or #import) in the c file which you want to access a particular function from the other file. It's really easy to do, and you'll do it *a lot*, but the specifics of how it all works aren't all that practical to lay out in a forum post (at least, not something I have time to do at the moment ). Unless someone else offers an explanation here, this is something best answered in your favorite C book or Google hit.

If you're just fooling around with something and not necessarily working on a real project(if you are though listen to what jake said), I'd either create a single .h file for your function declarations and make sure to include/import it into every .c file.

Actually, I do that too quite frequently -- one .h for many of the function declarations for several .c files. It's certainly not very modular, but there isn't really anything wrong with it if it makes sense, and that's how you want to group things.

Splitting in several files is an absolute must for organising your code. Don't make them too many to begin with, split into separate functionality. In particular, identify code that you are likely to use in your next project, and take that out to a reusable unit.

You don't need to bother with that initially; for me it is something that often happens when moving from the one project to the next. Then I see what code I'd like to copy-paste, and instead of copy-pasting, I make it a common module for both. Why didn't I make it reusable straight away? Because when I first wrote it, it was immature, and maybe I didn't know if I would use it again.

I prefer one source file - one header file. With one header file for many source files, you can't make the modules independent of each other. Making totally independent reusable units is the key to reusable code.

Of course, that depends on the problem. A complex problem may require much code, best split into many files that are highly dependent of each other. That set of files can be like a library, with a bunch of internal source and header files, but having one single header for using it externally makes sense. It is fairly common.