C header system alternatives for small projects?

Question

Recently I tried to implement the header file system into my project and it went terribly.

The main grievances I have are:

• how is one supposed to keep track about which.h files have corresponding.c files that need to be compiled into objects, and which.h files are solo?
• looking into the code of the GNU C Library, it is pretty obvious that header files contribute to unreadable and (probably) unmaintainable code
• it is annoying to add a.c file to the compilation command each time you add a new header file
• it is tiresome to have to write two files - one to announce a promise that you will provide a.c file in the future (these function prototypes or whatever they are are highly unintuitive), and then write the actual functions in the.c file. The worst thing - you can't follow the code because the.h file (which you will encounter in the main.c) doesn't link to its.c file in any way. But at the same time, the.c file includes its.h file for some reason (maybe to get the needed macros if they exist)

On the other hand I do understand that the header file system is needed for:

• avoiding circular dependencies
• compartmentalization
• avoiding redundancy

So I am wondering if the things that header files fix could perhaps be accomplished in some other way that is more intuitive, more readable, and less of a pain?

For instance, if we added the ifndef part to a.c file, we could include other.c files.

//main.c
#include "special.c"

//special.c
#ifndef SPECIALC
#define SPECIALC
    #include <stdio.h>
    void some_func(void){puts("hello")};
#endif

Looks nice. Now you can literally follow the trail, and don't have to worry about keeping track about which.c files you need to append to the compilation command.

But I know this won't work as nicely as I think. But I just wanted to show what an ideal solution would look like if it could work.

Maybe you know some solution that comes close to this ideal.

Answer 1

The only other solution to your problem is to directly include the source file into main.c but it'll cause many weird dependency problems. You will have to recompile the whole thing even if you modify only one file's function.

how is one supposed to keep track about which.h files have corresponding.c files that need to be compiled into objects, and which.h files are solo?

By naming the corresponding .c and .h files the same. They should be exactly one each or else you'll end up with spaghetti.

looking into the code of the GNU C Library, it is pretty obvious that header files contribute to unreadable and (probably) unmaintainable code

No it's not. Ignore the .h files, and everything is readable again. If you want to change any symbols, use your IDE's refractor or bulk name changer; whatever there is.

it is annoying to add a.c file to the compilation command each time you add a new header file

That's why we use build systems or some basic scripts at the very least. Your IDE will manage it itself and if you're not using an IDE, make a basic script for those stuff or use a build system like Cmake or Meson .