[AccessD] Global Variable

Scott Marcus marcus at tsstech.com
Wed May 18 07:25:44 CDT 2005


Drew,

There are many things in life that are bad practice. Bad practice does
not make something wrong; it's just not the wisest choice. Same goes for
programming.

It seems that you make arguments for bad practice on things like integer
declaration (which one could argue as valid just like you did for
globals), without reason, and you raise hell because others did the same
thing about globals. Then when given valid reasons, you try twisting the
reason into something that was not said.

Case in point, no variable ever changes auto magically, but you make it
sound like JC is saying that. What he is saying is that any developer
using the code (and face it, some of us are on teams with multiple
programmers) can dink with the variable, most of the time by accident,
outside its intended use.

Most of the issues I've seen where globals bring to light why they are
bad practice involve a second developer storing a value that was never
intended to be placed in the variable that causes another function
(seemingly unrelated), written by another developer, to crash and burn
(not an error per se but definitely not a value that the function would
expect)(I've seen this one before, a global called sex that contained
the invalid value of 'neutered male'). This is just one facet of
spaghetti code. Is spaghetti code bad practice? But if the program works
and is bug free... It's still not a valid argument.

There are valid uses of lots of programming things that in general are
bad practice. This does not mean you should never use them. I would much
rather tell a new developer that a global is bad practice and then later
show them an instance where it is needed, than not pointing out the bad
practice and then helping them fix the mess they got themselves into.

Maybe you take offense to the bad practice comment because deep down you
know you use global variables too much. Or maybe you just like to debate
for the sake of debating.

Scott Marcus


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
DWUTKA at marlow.com
Sent: Tuesday, May 17, 2005 6:15 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Global Variable

Not sure what you mean.  Are you defending the claim that Global
Variables
are 'bad practice' or not?  If you are, why are they bad practice?

Drew

-----Original Message-----
From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
Sent: Tuesday, May 17, 2005 4:39 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Global Variable


LOL. And for an encore, should I demonstrate proving ANOTHER negative
like why you didn't prove anything???  <g>

Charlotte Foust


-----Original Message-----
From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com] 
Sent: Tuesday, May 17, 2005 1:53 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Global Variable


LOL.  Well Charlotte.  Give me a valid reason.  I think I have proven
all of the current ones incorrect.  If you don't think so, which ones?

Drew

-----Original Message-----
From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
Sent: Tuesday, May 17, 2005 3:34 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Global Variable


Give it up, John.  When Drew decides no one elses arguments make any
sense, there's no reasoning with him. ;->

Charlotte Foust


-----Original Message-----
From: John W. Colby [mailto:jwcolby at colbyconsulting.com] 
Sent: Tuesday, May 17, 2005 1:06 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Global Variable


ROTFL.

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
DWUTKA at marlow.com
Sent: Tuesday, May 17, 2005 3:58 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Global Variable


You have said that using Globals is bad practice, which it is not.  That
is my argument.  The misuse is.  'Getting carried away with'...well,
that's an iffy statement, because you have to judge what is 'getting
carried away with' and what is not.

Drew

-----Original Message-----
From: John W. Colby [mailto:jwcolby at colbyconsulting.com]
Sent: Tuesday, May 17, 2005 2:02 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Global Variable


Would "getting carried away with globals" be considered misuse of
globals? If you look back to the first post you see that is what I
warned against. Notice I did NOT tell him that in his particular case he
should not use a global.  

YOU have built an argument for your own amusement, but in the end it has
enabled us to discuss the issue which is a good thing.

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
DWUTKA at marlow.com
Sent: Tuesday, May 17, 2005 2:40 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Global Variable


Ah.  There's the issue.  'If a global doesn't need to be SET by project
wide code'.  Okay.  Now, that I will back down on.  I personally don't
have an issue with setting it one place, and using it other places.  No
problem there.  But what if you are constantly using (reading and
writing) it from many places in your project.  Does a Global Variable
fit the model?  Of course!  Honestly, I use classes too, and will make
read only properties 'read only'.

Drew

P.S.-- Still doesn't make Globals bad practice, only misuse of
globals...which is still my position.



-----Original Message-----
From: John W. Colby [mailto:jwcolby at colbyconsulting.com]
Sent: Tuesday, May 17, 2005 11:52 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Global Variable


I understand completely Drew.  In order to not use globals you have to
THINK and you are too busy typing to do that.

Correct me if I am wrong, but nowhere did I advocate any code like you
mentioned.  Can you show me where in my email I advocated that?  What I
said was that if a global doesn't need to be SET by project wide code
then it doesn't need to be global.

I have seen in your previous posts where you mention saving keystrokes.
Understand that I am NOT a data entry person.  My job is to design well
engineered systems.  If that means more keystrokes, so be it.  

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
DWUTKA at marlow.com
Sent: Tuesday, May 17, 2005 11:32 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Global Variable


Tighter?  If I looked at code like this:

Dim MyModuleLevelString as String
Private Function SetModuleLevelString(strValueToSet As String)
MyModuleLevelString=strValueToSet End Function

I would think the developer was getting paid by the key stroke.....not
that it was 'tight code'.

Drew

-----Original Message-----
From: John W. Colby [mailto:jwcolby at colbyconsulting.com]
Sent: Tuesday, May 17, 2005 6:59 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Global Variable


Gustav,

This is nothing new, and not something I take credit for figuring out.
It is not uncommon when you work with classes to have methods set the
values of and return the values from class properties.  In fact with
classes you have syntax constructs specifically for this - property
get/set/let.  You can, if you wish, dim a variable public in the class
header and then it is just read / write to anyone with a pointer to the
class.  Or you use a property get and or set/let in whatever combination
you need.  A read-only value has only a property get.  A Write-only has
only a property set (not very common) and a read / write has a property
get and property let/set.

The objective is simply to control how the variable is read/written.
Since the variable is dimensioned private to the module (or class), only
a function in the module or class can set the value, and only a function
in the module or class can return the value.  To make a property "read
only", create only a function that returns the value, but do not build a
function that sets the value.  Then only the class or module itself can
set the variable.  

For example as the module initializes, perhaps some value is pulled from
a table and written into the variable.  Then a function returns the
value to any process that needs the value.  Or perhaps the value is
calculated by some math transformation using other values in other
variables.  The other variables are set by processes, but in order to
read out the value, a function either returns the variable directly or
returns the value of the mathematical transformation using the values in
the other variables.

This is not new stuff, I did not invent it, but it is commonly used to
"replace" global variables such that the CONCEPT of a global variable
exists (can be seen from anywhere) but still protects the variable from
being written when it shouldn't be or by processes that should not be
able to write to the variable.

And yes, it is more work.  It is just one of those things that you do or
your don't.  If you accept the practice, then you start thinking about
protecting variables, using variable scope, and using functions to set /
return values where appropriate.  It becomes habit and your code becomes
a little bit tighter.

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Tuesday, May 17, 2005 6:30 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Global Variable


Hi John

Well, here we have full control on where functions put their nasty
fingers.

I haven't managed yet to build self generating code; to some this would
indicate a brave new world, to some it would be a nightmare - functions
creeping around and attacking our globals and eating our children...
gosh. But worse, they would soon learn how to take advantage of your
functions to change those "private variables"! Be prepared.

/gustav

>>> jwcolby at colbyconsulting.com 05/16 10:58 pm >>>

..  Making this a global allows functions
that have no business setting these variables to change them.  By having
a private variable returned by a public function, any function that
needs the information can get it but cannot modify it.

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

 




NOTICE:  This electronic mail transmission is for the use of the named individual or entity to which it is directed and may contain information that is privileged or confidential.  If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of any information contained herein is prohibited.  If you have received this electronic mail transmission in error, delete it from your system without copying or forwarding, and notify the sender of the error by replying via email or by calling TSS Technologies at (513) 772-7000, so our address record can be corrected.   

Any information included in this email is provided on an “as is” and “where is” basis, and TSS Technologies makes no representations or warranties of any kind with respect to the completeness or accuracy of the information contained in this email, or with respect to any other matters communicated in this email.  TSS Technologies hereby disclaims any and all express or implied warranties of any kind.  Nothing in this email shall be construed to create any kind of contractual or binding agreement or commitment by or on behalf of TSS Technologies, Inc., the recipient, or any third-parties.



More information about the AccessD mailing list