Re: headers - best practice?
On Jul 13, 9:19 am, Colander <colan...@gmail.com> wrote:
On Jul 13, 12:27 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
makc wrote:
suppose you have a .cpp file that needs things from headers A and B,
and it is known that header A already includes B. should I still put
include B in .cpp just in case I will move some code related to B only
some day? or should I keep those countless #includes to the minimum?
what are other pros/cons?
Headers are for the compiler to read, they are not documentation.
I don't agree. I do think it's best to "Don't repeat yourself". This
makes it necessary that the headers are the documentation, look at
Doxygen for example, a couple of well aimed comments and all will
understand what the code will do.
The whole point of Doxygen is that headers aren't documentation.
You need to generate a different format for it to be useful.
(Significantly, the important point is often what isn't included
in the Doxygen generated files.)
IMHO, however, Doxygen does do things backwards. Generally
speaking, you want to write the documentation (external
specification), and generate the header from it. The problem is
that the header also usually needs additional information (e.g.
private data members) which aren't part of the interface
specification.
If I write separate documents the chance is very great there
will be discrepancies between the code and the documentation.
In which case, the code will fail review.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34