Hi,
while I wouldn't be against it if we were to start writing a whole new project, we have tons and tons of files already doing doxygen in the .c files, so I wouldn't start now doing differently and have mixed codebase. Also moving all current doxygen documentation to header files sounds like a huge tasks with lots of changes in lots of places, so it looks like a no-go to me.
I don't see the requirement to move all function documentation to the header in one go. New code should have it in the header, old code can keep it until someone moves it (or touches it).
Moreover, I don't really see a good reason for moving documentation to header files other than:
- "My foobar editor decides it only parses header files"
- A user may want to inspect documentation through installed -dev
packages in /usr/include/osmocom/.
It comes down to those two points. I guess most editors doesn't take up the documentation, when located in a distant directory which isn't part of the current project. I also find it strange that I've have to read the code (.c file) of a function to see the documentation instead of just looking into the header file.
Is actually doxygen explicitly enforcing the API documentation to be on header files? I doubt it.
AFAIK, doxygen doesn't care, it's about the documentation style.
Best, lynxis