Putting them into the source is what was done for fltk2.0 From my experience they do tend to get out of sync, and lots of inline functions are undocumented.
So it may be better to document the inline functions in the header file. I definitely would document non-inline functions in the source code. These are the ones that are more complicated and the doxygen comments will certainly get out of sync unless they are right there where the programmer sees them. At DD they did try to document in the header and the comments were always quite wrong and/or misleading. Also an inline function that has a complex description should be put in the source code, as the long comment can detract from the readability of the header file. But these are very rare. I don't like the "*" at the start of every line. It makes it impossible to cut/paste text from the output of doxygen. matthiasm wrote: > > On 07.09.2008, at 20:01, Roman Kantor wrote: > >> Not sure why we need to distinguish >> between inline and non-inline functions for placement of doxygen >> comments... > > > Doxygen comments always refer to the following function or class. Since > inline functions only appear in the header file, you either have to > doxygenate them there, or you put the doxygen comment into any source > file, starting with /** \fn myFunc(int, int) . It will then create a > reference even if the function is declared and implemented somewhere else. > > I very much dislike strewing doxygen comment into source *and* header > files. To me, it just makes it hareder to find the actual documentation. > Since the header contain all externally visible structures, I prefer the > headers. It does require a bit more discipline if the functionality of > an existing function changes. > > Matthias > > ---- > http://robowerk.com/ > > _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
