Solved Option Explicit?

[Gasman]

Does anyone know a good reason for NOT using Option Explicit?

Why MS, do not have it set as default, I have no idea.

So that got me to thinking, perhaps there is a valid reason, which escapes me completely.

 

[The_Doc_Man]

You can set it as a default in File >> Options >> Current Database, I believe.

As to why people didn't always use Option Explicit? The original 1964 version of Beginner's All-purpose Symbolic Instruction Code, or BASIC - the granddaddy of VBA, didn't require you to DIM anything because beginners had no idea about declarations. It didn't even have the option setting, or if it DID, I never saw it. The original goal of Kurtz and Kemeny (BASIC's creators) was a simple language that people could use with minimal training. See also: https://en.wikipedia.org/wiki/BASIC

I first used BASIC in 1968, I believe, when our PDP-10/TOPS-10 system arrived at UNO. Early BASIC from that period dynamically created variables when first referenced. Obviously, if you DIM it up front, that is the first reference... but if you just created the LET X = statement right from scratch, the creators of BASIC didn't want to blow you up with error messages just because you didn't use DIM X. Instead, they created the equivalent of a VARIANT data type (without calling it that, because I don't recall that they had that data type). And that is exactly the behavior that happens now when you start programming without Option Explicit. Also consistent with the earliest versions of BASIC, modern VBA expressly supports LET-coercion, the technique of formula analysis that does type conversions on-the-fly within the right-hand side of an assignment statement.

 

[MajP]

So that got me to thinking, perhaps there is a valid reason, which escapes me completely.

I think MS truly believes they are doing you a favor and making life easy. Goes along with allowing you to put spaces and characters in field names, every template using macros instead of vba, default properties and methods, and things like MVF. All things to make your life simpler in the short run. Who wants to waste time declaring variables now when you can simply spend hours debugging later.

 

[Gasman]

You can set it as a default in File >> Options >> Current Database, I believe.

That might be, but why not by default?
I see so many snippets of code that show it is not set,and causes so many problems,because of that.

 

[The_Doc_Man]

That might be, but why not by default?

The simple answer is that originally when Windows and Access came out, MS was shooting for a lower-level audience (less technically astute, shall we say?) so they hid a lot of details and speed-bumps that would alienate new customers who were not so computer savvy. This is carried-over behavior that has never been cleaned up.

The whole concept of Windows is actually that ORIGINALLY Windows didn't actually do anything except create a command line for you and run it through the CMD processor, because Windows was just a transformation layer that sat on top of CMD. Left-click was always "SELECT" and double-click was either RUN (for .EXE and .CMD) or OPEN (for anything else). Right-click was always the list of things known to work for that file type. When you right-clicked on a file, it looked at the file's type to see what could happen for files of that type and then it gave you the list of options for which it could build that command based on the file you selected. That was needed because command-line operation was too error-prone and it required people to be able to type.

Sometime around the advent of WinNT, that changed because WinNT became the foundation and CMD became the layered product. If you look at modern Windows, you will see something called "Associations" which means you can define things that can be done for a known file type. The Associations is a still-functional translation table that identifies what task to run when someone launches a file of a particular type.

 

[Gasman]

That argument seems to be the opposite of using the statement?
If you are new or clueless in coding, you need Option Explicit, surely?
I still prefer to see file extensions, and not rely on some stupid icon.

Regardless, can you think of a good reason not to use it?

 

[Edgar_]

Not my doing, but there are a lot of people who write code declaring variables without a type, or even without declaration. People coming from JavaScript, for example, they would happily write VBA code without Option Explicit. Then there's those that prefer their type being defined, and thus TypeScript was invented.

As a side note, plenty of Excel users write code without Option Explicit too. With enough practice, like everything, they probably find it's an advantage.

 

[The_Doc_Man]

That argument seems to be the opposite of using the statement?

In the final analysis, you have two choices. You can remember that you ALWAYS must define variables before using them in order to prevent crashing your code, OR you can make the language fault-tolerant by dynamically creating variables when needed. In the early days, the clamor was "fault-tolerant, please." Now there are those for whom data-type accuracy is critical and fault-tolerant variable creation is seen as "inaccurate."

Just remember these old rules: (1) The customer is always right. (2) When in doubt see rule 1.

And to put it into perspective, remember that early computers were occasionally a bit cryptic to use, causing a lot of customer complains.

 

[isladogs]

I asked this some years ago.
Its not set as default as VBE settings such as Option Explicit apply across all Office apps (as you can easily check)

I just asked CoPilot:
Q: Remind me why Option Explicit isn't set as default in Access

A: Great question, Colin — and one that’s sparked more than a few groans from seasoned Access developers over the years.

The short version:
Access doesn’t set Option Explicit by default because of a legacy design decision dating back to Access 2000, when Microsoft aligned its VBA editor with the rest of the Office suite. At the time, Word and Excel didn’t require variable declarations by default, so Access followed suit.

The longer story:

• In Access 95 and 97, modules did include Option Explicit by default.
• But when Access 2000 adopted the shared Visual Basic Editor (VBE), Microsoft chose to match the behavior of Word and Excel — which meant no Option Explicit unless manually enabled.
• This was arguably a misstep, since Access is a strongly typed database environment, and undeclared variables can wreak havoc on data integrity and debugging.

 

[Gasman]

Thank you Colin.
If I was MS, I would have gone the other way.

 

[isladogs]

Me too. Unfortunately backwards compatibility means it won’t ever be changed

 

[GPGeorge]

I think MS truly believes they are doing you a favor and making life easy. Goes along with allowing you to put spaces and characters in field names, every template using macros instead of vba, default properties and methods, and things like MVF. All things to make your life simpler in the short run. Who wants to waste time declaring variables now when you can simply spend hours debugging later.

My theory is that they know why it's a bad strategy but they have chosen not to implement the more appropriate Option Explicit because it would break thousands of apps and confuse people.

Not every template uses macros, btw. Check out Northwind Developer....

 

[The_Doc_Man]

VBA is weak typed because it allows implicit type conversions. It can automatically convert data types. e.g. a string can be multiplied by a number, and VBA will convert the string to a numeric type as needed. VBA's default type is a Variant, which can hold any type of data. That flexibility makes it a weak typed language. However, using Option Explicit enforces strong typing. Even if MS were to make Option Explicit the default, any existing code without it would still work.

The implicit type conversions - called LET coercion - are another remnant of backwards compatibility as mentioned by Colin (Isladogs) and GPGeorge. Wise or not, LET coercion appears in the 2014 VBA Language Reference as a thing that WILL occur. Yes, a numeric string can be multiplied by a number because for backwards compatibility, string/numeric is slightly ambiguous. You can't have alphabetics in a number string and use the whole string - but as a poor man's parser, you can use the leading characters in a number string up to the first non-numeric character.

 

[Gasman]

That's what I thought too but I'm not sure how changing the default to be Option Explicit would change existing applications since it only comes into play when you create a new module. If you take an old db and change the default to Option Explicit, no existing modules are affected. The app still works or it doesn't.

I have downloaded members dbs from here and other sites.
I find something has not been declared. I add Option Explicit, and then it does not compile, which you would expect.

I add a few more missing declarations, but if there a large number, I just state that and leave it back to the user to tidy up.

 

[sonic8]

Why MS, do not have it set as default, I have no idea.

"Don't make me (the user) think!"
This is powerful and valid design principle for UX design.
To declare a variable before use, you must think about its name and type in advance. This slows down inexperienced users quite a bit and regarding the type they may not have a clue.

Of course, undeclared and potentially mistyped variables may cause significant debugging work later. Nonetheless, making variable declaration optional lowers the bar of entry to new users.

I don't agree with this design decision, but I see that it also has some merit.

 

[The_Doc_Man]

I think every time you need to recompile, such as editing a line of code and saving it as the trivial example, Option Explicit gets considered. However, VBA in Access is compile-on-need, not necessarily every time you launch a form or report. If you compiled a module and have not made any changes, it doesn't compile again on launch. (Of course, if you DID edit the module to include "Option Explicit"... that IS a change to the code!)

 

[sonic8]

It's a Pre Compile Directive

Loose the "Pre".

 

[CJ_London]

However, VBA in Access is compile-on-need, not necessarily every time you launch a form or report

Just as an aside, I have a db where I experiment with code, forms, sql etc. must be over 20 years old (or at least old code etc) as it was upgraded from 2003 to 2010 15 years ago.

Now I have moved to 64bit access, if I create a simple test form with a bit of code behind an event and try to open it, the compiler tells me some api’s in another module (which I’m not using) are not 64bit compliant.

Implication being that the whole project is compiled on form open - or perhaps just reviewed?

 

[sonic8]

Now I have moved to 64bit access,

If the database application was created in 32bit and you open it in 64bit Access the first time, the whole project needs to be recompiled for 64bit. - Believe it or not.

 

[sonic8]

IIRC, by default, the vb.net and vb6 compilers enforce explicit variable declaration?

I'm not entirely sure about VB6, but I think it does.
A definite Yes for VB.Net. And it's a compiler option that applies to all files in a project. You don't need to put the Option Explicit statement in any file unless you want a particular behavior for one specific file overriding the global option.