Using header files is great when starting new projects. When I wrote my first game engine, I tried to keep everything in .h files. There are two benefits:

A minor one, but still saves some time: You don't have to think about build system. Just compile a single .c file on the command line. You can quickly add and remove .h files while prototyping, without having to add/remove files to the project.

A major one: is that you cannot create cyclic dependencies. This helps to get your call hierarchy right. When using header files only, the only way to get cyclic dependency is to use a forward declaration and every time you feel like you need to do that, a big red flag is raised in your mind. And then you start to think how to do it properly. This is even more important in C++ where you have to think about responsibilities of every class. It prevents you from creating too coupled code.

When the project grows and compilation times get long, you should split all of those into separate compilation units, so that you can use multi-threaded builds (via ninja, or make -j).

File->New Project isn't that hard.

It's not uncommon in game development to do 'unity builds', by basically including all code to get a single compilation unit. It can reduce build times and the compiler has more options for optimizations (inlining, mostly). This doesn't require putting everything in header files, just including the .c files gets you the same result. But if you're doing unity builds the distinction between header files and source files is basically reduced to the file extension anyway...

I think Ryan just wants a single compilation unit, for the time being. I would personally just put all the code in one file if it's this small (though I think some text editors are not good at editing one file from multiple views, so I can see that being annoying for some).

I know that using .c and .h files is the traditional way of doing it in C, and I started the engine this way, but to be honest, is there any gain to it in this scenario?

The headers are library code, and having more files just means more maintenance and build complexity. Is there another advantage I am not aware of?

The question should probably be what you gain from the header files? If you just want the simplicity you can "#include \"some_file.c\"" instead. Functionally it's no different, but it's less surprising to other people and it's an easier transition to a real build system if/when you need it. I think the reason it's being raised is because people think your writing a header only library.

In my experience, including `"some_file.h"` is more common than `"some_file.c"`. I also like knowing at a quick glance what the entry point/main file is. That's less explicit when all the files have the same extension.

You can read some of the criticisms here https://en.m.wikipedia.org/wiki/Header-only

None of them seem relevant for a small-scale unitary project.

Even a large project like SQLite is provided as a single, unified header file!

A better resource is this:

https://github.com/nothings/stb/blob/master/docs/stb_howto.t...

There's an important difference between C++ style header-only libs, where the implementation is often done in inline code (especially for template-heavy APIs) and thus visible in each compilation unit (which is indeed bad for compile times), and "STB-style single-file libs", where the implementation is only visible in a single compilation unit.

The difference between a single .h file and a .h/.c pair is really just different packaging for distribution and integration into projects.

Good question... (In fact, a small project with a single .c file does not even need include files.)

Not bothering to learn how to deal with compiler toolchains.