Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Using Doxygen with C, do you comment the function prototype or the definition? Or both?

I'm using Doxygen with some embedded C source. Given a .c/.h file pair, do you put Doxygen comments on the function prototype (.h file) or the function definition (.c file), or do you duplicate them in both places?

I'm having a problem in which Doxygen is warning about missing comments when I document in one place but not the other; is this expected, or is my Doxygen screwed up?

like image 274
jparker Avatar asked Aug 13 '09 13:08

jparker


People also ask

How do you comment a code on Doxygen?

doxygen Getting started with doxygen Commenting your code//! //! ... text ... //! Note the 2 slashes to end the normal comment block and start a special comment block.

How do I comment out a code in Doxygen C++?

To create a Doxygen comment from scratch: Type one of the following symbols: /// , //! , /** or /*! and press Enter .

Should Doxygen comments be in header or source?

The common sense tells that the Doxygen comment blocks have to be put in the header files where the classes, structs, enums, functions, declarations are. I agree that this is a sound argument for a libraries that are mean to be distributed without its source (only headers and libs with object code).

What are Doxygen comments C++?

A special comment block is a C or C++ style comment block with some additional markings, so doxygen knows it is a piece of structured text that needs to end up in the generated documentation. The next section presents the various styles supported by doxygen.


2 Answers

For public APIs I document at the declaration, as this is where the user usually looks first if not using the doxygen output.

I never had problems with only documenting on one place only, but I used it with C++; could be different with C, although I doubt it.

[edit] Never write it twice. Never. In-Source documentation follows DRY, too, especially concerning such copy-and-paste perversions.[/edit]

However, you can specify whether you want warnings for undocumented elements. Although such warnings look nice in theory, my experience is that they quickly are more of a burden than a help. Documenting all functions usually is not the way to go (there is such a thing is redundant documentation, or even hindering documentation, and especially too much documentation); good documentation needs a knowledgeable person spending time with it. Given that, those warnings are unnecessary.

And if you do not have the resources for writing good documentation (money, time, whatever...), than those warnings won't help either.

like image 93
gimpf Avatar answered Sep 22 '22 16:09

gimpf


Quoted from my answer to this question: C/C++ Header file documentation:

I put documentation for the interface (parameters, return value, what the function does) in the interface file (.h), and the documentation for the implementation (how the function does) in the implementation file (.c, .cpp, .m). I write an overview of the class just before its declaration, so the reader has immediate basic information.

With Doxygen, this means that documentation describing overview, parameters and return values (\brief, \param, \return) are used for documenting function prototype and inline documentation (\details) is used for documenting function body (you can also refer to my answer to that question: How to be able to extract comments from inside a function in doxygen?)

like image 24
mouviciel Avatar answered Sep 22 '22 16:09

mouviciel