[AccessD] Option Explicit Statement

LOL, you have been creating a serious breach of national security, have been
placed on all of the no-fly lists, you mail is being opened without a court
order, your phone calls are tapped, all email in and out of your various
computers are being processed for links to you know who.

Man, you are screwed already.  I would suggest you try and slip across the
border and disappear before you end up in Gitmo.  And DON'T use your credit
cards, they will hunt you down!

Good luck and please leave your desk in order as you leave.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Keith Williamson
Sent: Thursday, January 18, 2007 11:29 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Option Explicit Statement

Okay, Okay!!  {hands up in the air, waving white flag}

I give up, VBA Police!! I'm a bad person....take me in!!

:)

Keith E. Williamson | Assist. Controller| kwilliamson at rtkl.com

RTKL Associates Inc. | 901 South Bond Street | Baltimore, Maryland
21231-3305

410-537-6098 direct | 410-276-2136 fax | www.rtkl.com


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby
Sent: Thursday, January 18, 2007 11:08 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Option Explicit Statement

There is no performance impact one way or the other AFAIK.  However "I
always" is way different from "the system will not allow".  One depends on
the user enforcing the rule, the other allows the system to enforce the
rule.  Furthermore it disallows "implicit declarations" which is where the
"explicit" in Option Explicit comes from.  

As an example, the code below is allowed if Option Explicit is not declared.


Sub DoSomething
	x = 10
End sub

In essence the variable X was never dimensioned, and so it is dimensioned at
the point that you try to use it.  

This allows spelling errors to creep in to your code.  For example:

Sub DoSomethingElse
Dim aDate as date
	aDate = date()
	aDte = aDate+1
End sub

Notice that I dimensioned aDate as the variable I wanted to use, but I
actually USED aDte to increment the date.  

Setting Option Explicit will not allow such implicit declarations and will
cause a compile time error.

I used to shudder every time I inherited a project where the developer did
not set Option Explicit because I just knew I would have to go find and fix
such bugs before I could do any real work.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Keith Williamson
Sent: Thursday, January 18, 2007 10:30 AM
To: Access Developers discussion and problem solving
Subject: [AccessD] Option Explicit Statement

My database performance analyzer is recommending I use Option Explicit
Statements in my two main forms.  I understand the benefits of doing so,
from a programming error recognition standpoint.  Is there any benefit from
a performance standpoint?  I pretty much always declare my variables
anyway...so I don't really see a benefit there (no variants in my
programming.)

 

Any ideas?

 

Regards,

 

Keith E. Williamson | Assist. Controller| kwilliamson at rtkl.com

RTKL Associates Inc. | 901 South Bond Street | Baltimore, Maryland
21231-3305

410-537-6098 direct | 410-276-2136 fax | www.rtkl.com <http://www.rtkl.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