declarations in include files: how do YOU feel?

[Mark A Terribile]

> I would like to find out how the "experts" feel about a coding practice, so
> I don't develop a bizarre style (bizarre with respect to the general body of
> usage).  I hope this doesn't start a philosophy war of some kind.

It will, never fear.  I hereby fire the first salvo.

> ... suppose I have a bunch of routines ... packaged into a lib.a, and there
> is an associated include file "lib.h" ...  Should the lib.h file contain
> extern declarations for everything in lib.a, or not?

> case 1:  shotgun approach.  declare all the routines contained in lib.a
> advantage:  user doesn't need to.
> disadvantage: "scope" is not micro-managed.  labels are in scope
> everywhere, even labels not used in actual references.

Advantage: the declarations are available and they are *RIGHT*.  When the
system is changed or ported, the correct versions are available to all
programs that use them.  This is important for obvious reasons; it's even
more important for ANSI C.
 
> case 2:  "anal" approach.  no declarations in lib.h.  User needs
> to type in the declarations in every function that makes a reference.
> advantage (???): user sees declarations in same file as usage.

Not an advantage.  The programmer has to get them right and he's got no
machine checking (save, possibly for LINT, which, IMnsHO, is a botch and a
disfigurement).

> scope of labels is managed according to program design.

How is this an advantage?  If you really feel that you need it, use #ifdef's
to surround ``reasonable'' groups of function names--and #else's controlling
#define's that will make the programs invalid if they need a declaration and
don't have it.

> If my goal is to be portable and non-eccentric, what should I do?

If your goal is to write reliable software, which should you do?
-- 

(This man's opinions are his own.)
>From mole-end				Mark Terribile