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: 
You *could* do that, but we like to separate C programs into separate *translation units*, chiefly because:

1. It speeds up builds. You only need to rebuild the files that have changed, and those can be *linked* with other compiled files to form the final program.
2. The C standard library consists of pre-compiled components. Would you really want to have to recompile all that?
3. It's easier to collaborate with other programmers if the code base is split up into different files.
While you can still write your program in a modular way and build it as a single translation unit, you will miss all **the mechanisms C provides to enforce that modularity**. With multiple translation units you have fine control on your modules' interfaces by using e.g. `extern` and `static` keywords.

By merging your code into a single translation unit, you will miss any modularity issues you might have because the compiler won't warn you about them. In a big project this will eventually result in unintended dependencies spreading around. In the end, you will have trouble changing any module without creating global side-effects in other modules.