header file documentation style

Christian Stimming stimming@tuhh.de
Sun, 8 Dec 2002 03:21:19 +0100


-----BEGIN PGP SIGNED MESSAGE-----

Benoit: the doxygen configuration works really nice. It finally looks as if we 
will arrive at a "real", exhaustive engine/gnucash API documentation. Very 
nice!

Just a few remarks about how IMHO doxygen's features can be used most 
efficiently. (I went through all this only recently -- HTML like  
http://openhbci.sourceforge.net/doc/api/classHBCI_1_1Bank.html is the 
outcome.) 

* I'd propose to not use the @brief comments in the regular case. In functions 
like xaccTransSetDescription, it is already pretty clear what this does from 
the name. Therefore in this case the @brief explanation only makes it more 
difficult to browse through the list of all available functions (because of 
the extra line breaks) -- and makes it harder to see all functions that 
belong together. There might be a few functions where the @brief comment 
helps a lot in clarifying, where the name itself would not be enough -- those 
would be fine, of course.

* I'd propose to use the automated grouping of doxygen (/**@{*/ ... /**@}*/) 
rather conservatively. Those groups help a great deal in organizing functions 
that belong together i.e. work on the same types and/or do the same things. I 
think of it in terms of a C++ class definition -- in such a definition, I can 
see *all* functions (C++: methods) that work on this type (C++: class). Since 
originally doxygen would only give me the list of 100 defined functions in 
one particular header file, we can use these groups to break down the 100 
functions into reasonable-sized groups of stuff that belongs together. By 
this I mean: a) for a given type we should try to have as little different 
groups as possible, and b) to achieve this, a group should only be created if 
it contains at least 5...10 functions in it. Ex: There are ~80 functions 
related to the type Split in Transaction.h. Since no developer can see 80 
functions at the same time to pick the function he needs, we need to group 
these into logical groups. In this case, I came up with six different logical 
groups, each containing 10-20 different functions. I think it would be no 
good if there were much more groups than this, since then the developer will 
not be able to see all the groups at the same time. blablablable... gee  it's 
really getting late here. Hope you can follow so far.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iQCVAwUBPfKsn2XAi+BfhivFAQF4CQQAs4hztUZicO+esnR9pnR8I/Q9hveZF2Yy
q52g4kE4a0iTHLipD8bDsdJIPthhQLsfjt2eRuLVbGRxdgD+yA8Z9S4SKia5Ff9a
lDQWt4xgWuQomY0I1Iafo3P+QgEtVAKD6cGdqEjGvPfnvb/0QmPrE7ieuGMRVaqs
0YNIVFtTpHE=
=qo+L
-----END PGP SIGNATURE-----