[AccessD] Global Variable

John W. Colby jwcolby at colbyconsulting.com
Tue May 17 11:19:42 CDT 2005


Drew,

>If your app is overloaded with Global variables, if that is what you need,
it is what you need.

Or maybe you just have never tried very hard to do it a different way.  I
write some pretty large apps Drew.  I have apps with thousands of lines of
code, dozens of modules and dozens of classes.  Yet I have a handful of
globals in my apps.  If they are so necessary why don't I need them?  Are
you special somehow that you get all the "really hard things" that just
require globals?

>If you are not saying that they 'go away' as an argument, why do you
consider them 'bad practice' still?

Because anyone anywhere can overwrite them.  If a variable is "global" to a
module - dimmed PRIVATE in the header of the module, then only code in that
module can set / read the variable.  If a variable does not need to be
WRITTEN TO by code outside the module, then it should be a private variable
in the module header.  If objects outside the module need to be able to READ
the module, then you create a public function that returns the value of the
variable.  Because the variable is dimensioned PRIVATE, objects outside the
module cannot WRITE to the variable, but can use the function to READ the
variable.  That variable is not truly global, it is global to the module but
read only to the rest of the project.  

The concept of variable scope becomes very important in large projects.
Many different modules may have a variable named strTaxID for example.  Yea,
yea, not YOUR projects since you revile conventions, but other people's
projects.  Now, the strTaxID may be the company's TAXID in one module, but
an Employee's TaxID in another module.  By using scope and making strTaxID
private to the module then anyone can use strTaxID as it is useful to them
in their own modules yet not step on the usage of another module.  If you
just make everything in the damn world global, then strTaxID "belongs to"
the first developer to dimension a variable by that name and if anyone else
uses that name they "step on" the other developer's variable.  Maybe they
use it correctly, maybe they are sloppy programmers who don't consistently
dimension a variable, depending on VB to do it at the instant the variable
is used.  OOOPPPps, they just trashed something.

They don't trash MY something because unless it is absolutely required, and
those instances are truly few and far between, I dim all my variables
private and expose them exactly when and where they are needed outside of my
modules.  

I learned a lot of things writing code for Puritan-Bennett.  They make
ventilators and bugs in their code kill people.  Bugs in code for Aircraft
control systems kill people.  Bugs in interstellar spacecraft crash and burn
the space craft.  There are basic practices that are NOT difficult, they ARE
good practice and ANYONE can learn to do them.  If you do them then your
code is easier to read, easier to troubleshoot and (usually) allows fewer
bugs.

And yea, yea, you only write code by yourself, or for small apps, or other
bullshit excuses.  Good programming practices are good programming
practices, and poor practices are poor practices.  It is very easy to make
excuses, and it is not easy to be a methodical programmer, doing things "the
right way" just because that makes your program (and programming) better.

You pride yourself for thinking for yourself, and believe me, I applaud you
for that.  However there are practices that exist because the community at
large have learned things, have been exposed to situations that you haven't
been exposed to.  By just rejecting things because "I don't see any sense in
that" is quite all right when you are working on your own project for your
own purposes.  To do that when you are paid money to produce a product for
someone else is quite another matter.  Along with the salary comes a
responsibility to make the product you create conform to the "standards"
that exist in whatever industry you are in, programming in this case.  YOU
don't own the product you are creating, or at the very least you are being
paid to deliver a product to the client.  They have the right to know that
the guy that replaces you when you have stepped in front of the moving bus
isn't rewriting a pile of "I'll do it my way 'cause I think the rest of the
world is stupid".

There is plenty of room for innovation and art in programming, you really
don't need to trash conventions to prove anything.  Doing things the right
way can be a reward in itself as you become a world class programmer.

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:23 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Global Variable


Well, I will meet you on the 'when there is a valid reason for doing so'
part.  As for the used sparingly, well, I think that is not quite right. You
should dimension variables based on their scope.  Global variables are one
of three scopes.  If you need a Global variable, then dimension it.  If your
app is overloaded with Global variables, if that is what you need, it is
what you need.

If you are not saying that they 'go away' as an argument, why do you
consider them 'bad practice' still?

Drew

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


Drew,

I have a library (C2DbFW3G) that I use for all of my global code.  There are
thousands of lines of code, dozens of classes, hundreds of functions and NO
global variables.  They are completely unnecessary and no code outside of
the framework itself has any business directly setting variables in the
framework.  I have plenty of private variables, initialized by the framework
as it starts up, and I have a handful of functions that return the values in
the private variables in the framework, but the variables themselves are not
directly settable.  Even from inside the framework, there are NO global
variables.

In my applications, I have a handful of global variables.  I use them where
they are absolutely needed, and there are a handful of places in my app
where that is true.  I do NOT use them as a convenience to avoid
programming.  I do not use them to make something faster without knowing
that the speed increase is critical.  Excuses like "they speed up the app"
are just that, excuses.  Speed is not the end all and be all of an
application and speeding up something that is not a bottleneck at the
expense of poor programming practices is not a good reason to use a global.

The statement I made was "don't get carried away with them, they are
considered bad practice in general".  There is nothing about that statement
that is wrong.  They are considered bad practice "in general".  They should
be used sparingly.  Every tool has a purpose, and global variables exist,
therefore they must have a purpose.  I did not make any statement that
global variables should never be used, I simply said "don't get carried away
with them".

BTW I do NOT use "they go away" as a reason for not using them.  In my
estimation there should be no unhandled errors.  The error handler insertion
wizard that I co-wrote will assist the developer in getting an error handler
in every single function in the project if that is necessary.

There ARE valid reasons for using a global, but they are few and far
between.  There ARE valid reasons not to use global variables, many of them,
all related to avoiding and finding bugs.  If there were not valid reasons
for not using them, then you would not have scope for variables.  Your
opening sentence seems to imply that there is no good reason not to use them
and that simply is not true.  Let's meet in the middle and agree that
Globals should be used sparingly and only when there is a valid reason for
doing so.

John W. Colby
www.ColbyConsulting.com 

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





More information about the AccessD mailing list