Question: I come from a scripting background and the preprocessor in C has always seemed ugly to me. None the less I have embraced it as I learn to write small C programs. I am only really using the preprocessor for including the standard libraries and header files I have written for my own functions.

My question is why don't C programmers just skip all the includes and simply concatenate their C source files and then compile it? If you put all of your includes in one place you would only have to define what you need once, rather than in all your source files.

Here's an example of what I'm describing. Here I have three files:

```
// includes.c
#include <stdio.h>

```

```
// main.c
int main() {
    foo();
    printf("world\n");
    return 0;
}

```

```
// foo.c
void foo() {
    printf("Hello ");
}

```

By doing something like `cat *.c > to_compile.c && gcc -o myprogram to_compile.c` in my Makefile I can reduce the amount of code I write.

This means that I don't have to write a header file for each function I create (because they're already in the main source file) and it also means I don't have to include the standard libraries in each file I create. This seems like a great idea to me!

However I realise that C is a very mature programming language and I'm imagining that someone else a lot smarter than me has already had this idea and decided not to use it. Why not?

Answer: 
Because splitting things up is good program design. Good program design is all about modularity, autonomous code modules, and code re-usability. As it turns out, common sense will get you very far when doing program design: Things that don't belong together shouldn't be placed together.

Placing non-related code in different translation units means that you can localize the scope of variables and functions as much as possible.

Merging things together creates *tight coupling*, meaning awkward dependencies between code files that really shouldn't even have to know about each other's existence. This is why a "global.h" which contains all the includes in a project is a bad thing, because it creates a tight coupling between every non-related file in your whole project.

Suppose you are writing firmware to control a car. One module in the program controls the car FM radio. Then you re-use the radio code in another project, to control the FM radio in a smart phone. And then your radio code won't compile because it can't find brakes, wheels, gears, etc. Things that doesn't make the slightest sense for the FM radio, let alone the smart phone to know about.

What's even worse is that if you have tight coupling, bugs escalate throughout the whole program, instead of staying local to the module where the bug is located. This makes the bug consequences far more severe. You write a bug in your FM radio code and then suddenly the brakes of the car stop working. Even though you haven't touched the brake code with your update that contained the bug. 

If a bug in one module breaks completely non-related things, it is almost certainly because of poor program design. And a certain way to achieve poor program design is to merge everything in your project together into one big blob.
> 
> This means that I don't have to write a header file for each function I create (because they're already in the main source file) and it also means I don't have to include the standard libraries in each file I create. This seems like a great idea to me!
> 
> 
> 

The pros you noticed are actually a reason why this is sometimes done in a smaller scale.

For large programs, it's impractical. Like other good answers mentioned, this can increase build times substantially.

However, it can be used to break up a translation unit into smaller bits, which share access to functions in a way reminiscent of Java's package accessibility.

The way the above is achieved involves some discipline and help from the preprocessor.

For example, you can break your translation unit into two files:

```
// a.c

static void utility() {
}

static void a_func() {
  utility();
}

// b.c

static void b_func() {
  utility();
}

```

Now you add a file for your translation unit:

```
// ab.c

static void utility();

#include "a.c"
#include "b.c"

```

And your build system doesn't build either `a.c` or `b.c`, but instead builds only `ab.o` out of `ab.c`.

What does `ab.c` accomplish?

It includes both files to generate a single translation unit, and provides a prototype for the utility. So that the code in both `a.c` and `b.c` could see it, regardless of the order in which they are included, and without requiring the function to be `extern`.