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.