[vox-tech] global variables in C

Peter Jay Salzman vox-tech@lists.lugod.org
Fri, 20 Sep 2002 11:47:38 -0700


begin Tim Riley <timriley@timriley.net> 
> 
> 
> Peter Jay Salzman wrote:
> 
> > ok, first i'd like to apologize for bringing up such a tired subject,
> > but i'd like to understand this better.
> >
> > conventional wisdom says that you should avoid using globals.
> >
> > reading through some C books like the deitel book which is used at UCD
> > and SAMS "C primer plus", i find that they don't really address this
> > issue at all.  when i talk to people, i hear the same two reasons over
> > and over:
> >
> > 1. name clashing
> > 2. readability
> >
> > what i'd like to know is if this is all there is.  are there more
> > reasons why we should follow conventional wisdom?  or is this more of a
> > guiding principle and not something to be followed blindly?   it seems
> > like for some applications, like GUI and multi-thread programming, the
> > use of globals can really simplify things a lot.
> >
> 
> There is a guiding principle concerning the use variables --
> "Composite/Structural
> Design" by G. J. Meyers; Published by Van Nostrand Reinhold, New York, NY,
> 1978.
> 
> Meyers calls the sharing of variables between functions "coupling." He
> assigned all the possible
> ways functions can access variables to levels and gave each a term. From
> worst to best:
> 
> 1) Content coupling: having function A read/write a local variable of
> function B.
> (I don't think this can be done in C.)
> 2) Common coupling: having functions A and B share global variables.
> (This is the second worst.)
> 3) Control coupling: having function A tell function B what to do.
> 4) Stamp coupling: having function A pass an entire structure to function
> B.
> (This is what the FILE abstract datatype does.)
> 5) Data coupling: having function B receive every input parameter on the
> argument list.
> (If every function does this, including main(), there will be no global
> variables.)
> 
> Additionally, the scope of a function should be very limited. This goes
> into the topic
> Meyers calls "cohesion." If you follow the cohesion/coupling guidelines
> religiously,
> code maintenance becomes a breeze.
 
that's quite interesting; obviously a lot of thought went into those
ideas.

but i can certainly imagine option 5 (data coupling) being detrimental
to code maintenance.   when you look at a screen and see a thick dense
blob of code everywhere.   kind of like how perl can get.  as in, you're
normally black xterm background looks completely white when you don't
have your glasses on.

to be honest with you, i asked this question because someone challanged
me to argue the point of "globals are bad".   other than the 2 reasons i
gave above and the fact that it's conventional wisdom, i really can't
come up with much.  i was hoping to get some ideas.

pete