In all the code I see online, programs are always broken up into many smaller files. For all of my projects for school though, I\'ve gotten by by just having one gigantic C sour
Well, I am not an expert, but I always try to think in entities larger that a function. If I have a group of functions which logically belongs together, I put it into a separate file. Usually, if the functionality is similar, and someone wants one of such functions, he would probably need some other functions from this group as well.
The need to split up the single file comes from the same reason why you are using different folders for your files: people want to have some logical organization on the numerous functions, so that they don't need to grep the huge single source file for finding the needed one. This way you can forget about the irrelevant parts of the program when you are thinking about/developing some fixed part of it.
One more reason for splitting could be that you can hide some internal function from the rest of the code by not mentioning it in the header. This way explicitly separate the inner functions (which are needed only inside the .c
file) from the functions interesting to the outer "universe" of your program.
Some more higher-level languages have even extended the notion of "function belonging together" into "functions working on the same thing, presented as one entity" -- and called that a class.
Another historical reason for splitting is separate compilation feature. If your compiler is slow (this is often the case with C++, for example), splitting the code into several files means that if you modify only one location, the chances are high that only one file needs to be recompiled to pick up the changes. As the modern C compilers are not so slow in comparison to the typical processor speed, this may be not an issue for you.