declarations in include files: how do YOU feel?

[Steve Summit]

In article <179 at larry.sal.wisc.edu> jwp at larry.sal.wisc.edu (Jeffrey W Percival) writes:
>The situation is, suppose I have a bunch of routines that are packaged
>into a lib.a, and there is an associated include file "lib.h" that
>users need to include.  Should the lib.h file contain extern declarations
>for everything in lib.a?

By all means.  I'd say that this is the recommended standard
practice.  If you're using ANSI-style function prototypes, put
the prototypes in too, of course.  If you're not using
prototypes, you may leave out extern declarations for those
functions returning int.  (You may also leave them in, for
documentation purposes.)

>disadvantage: "scope" is not micro-managed.  labels are in scope
>everywhere, even labels not used in actual references.

I've never worried about micro-managing global scope.
If it's extern, it's global, so any module may call it.
Explicitly announcing their intention to call it (with their own
extern declaration) doesn't provide much more information than
does the actual call.  (For the same reason, I think that extern
declarations in local scopes are silly.  I understand that many
people like them, but I've never really understood why.)

>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.
>scope of labels is managed according to program design.

The disadvantage here, which is that the declaration (and, worse,
the prototype, if used) has to be replicated, with ripe
possibility for error, especially if the declaration has to be
changed.  This disadvantage, I would think, far outweighs any
loss of "micro scoping" caused by header file externs.

                                            Steve Summit
                                            scs at adam.pika.mit.edu