.header(ing) them off at the pass

[Jim Vlcek]

In article <1002 at ficc.UUCP> peter at ficc.UUCP (Peter da Silva) wonders
what the heck I'm talking about:

>> If one changes/deletes a variable in an #include file, one must
>> comb through every source file using that #include file and
>> change/delete every reference to that variable.
>
>If one deletes a global variable, one must comb through every source
>file that might be using that variable anyway. If one changes a variable,
>that's still true. Whether or not that variable is declared in an include
>file (for example, _ctype in ctype.h) or not. The same is true when you
>change an element of a structure declared in an include file.
>
>I don't understand this objection at all.

What I was saying was:  People are pointing out that putting
initializations in the .header file eliminates one variable
declaration/definition.  Hence, should one make a change or delete
such a variable, there will be one less change/deletion to make.  I
pointed out that this (one) extra change/deletion would pale compared
to the task of weeding out all references to that variable elsewhere
in the source code.

I have always believed in maintaining well-stratified conceptual
levels in my source code, to whatever extent possible.  In C, macros
help to clean up top-level source code somewhat, without the overhead
that excessive function calls would introduce.  Now, I consider a
.header file to be a template for program development; this is quite a
different conceptual level from actual data, which an initialized
variable represents.

In fact, it's not really the initialization which is bad, but the
*definition* (as opposed to declaration) of the variable in the .header
file which is wrong, never mind whether you initialize it or not.  It all
comes down to the difference between a programming environment and a
program environment.  The .header file describes the programming
environment; the preamble to the source module describes the program
environment.  A place for everything, and everything in its place.
-- 
Jim Vlcek
vlcek at caf.mit.edu
!{ihnp4,harvard,seismo,rutgers}!mit-eddie!mit-caf!vlcek