l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
October 7: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2002 Sep 20 12:13

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] global variables in C
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] global variables in C



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

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.