Well, it’s just a weekend discussion…
First up I must say that I like the way this thread is progressing.
It seems to me that it is moving away from some idea of absolute black and white into a more grey (gray, whatever) area.
From post #18…
>>I think some of these decisions reflect the influence of the previous experience of design team members.<<
My view, maybe, maybe not.
Not directed at post #18 but to all.
To explain my point of indecision I will need to digress away from the Me. Me! thing for a while.
When we look at code we are looking at a specific instance of that code. Here we are looking at VBA, not VB or SQL or DOS.
VBA is a different bucket of bolts altogether. Let’s digress and look at Option Explicit for a moment.
Because there is someone on this site (DWF) who disagrees with me when I say Option Explicit is off by default in VBA I will post some links.
http://msdn.microsoft.com/en-us/library/aa192490(v=office.11).aspx
http://www.fmsinc.com/free/NewTips/VBA/Option/index.html
http://www.cpearson.com/excel/DeclaringVariables.aspx
http://allenbrowne.com/ser-30.html
http://my.advisor.com/doc/17333
People should place their own importance on those links.
(And by the way, unloading Access and reloading Access does not change the last setting of ‘Require Variable Declaration’ that Access used for VBA. It seems to get the last setting from the registry, not from the reload of Access. In other words, if Access has ‘Require Variable Declaration’ set to True then when we unload and reload Access it will still be True, and the converse for False.)
So then why is Option Explicit important for this discussion?
VBA ships with Option Explicit turned off, whether we like it or not.
Why?
The reason, as I see it, is that VBA is not written for programmers, it is written for users. Be that a good or bad thing is open to interpretation.
When Option Explicit is turned off, and variables are not declared as anything in particular, then the user gets Variants. Variants can handle almost anything and, most of the time, the program works. (Or as someone once said to me; ‘it helps the phones stop ringing at Microsoft’. {That person has been trying to get Microsoft to default VBA Option Explicit to on for many years without success. He’s a good bloke but I disagree with him on this one.})
VBA is for people, not just programmers. The quicker those people get up to speed with it the better. People do not want ANSI ‘C’ with all warnings turned on; it would take months to get started. They want something they can use, and they want it now.
VBA is
the syntax, fault tolerant solution to that requirement. (Programmers may now cringe but if they do then it’s up to them, not Microsoft, to turn Option Explicit on. They have been given the choice and they can {should} use it.)
Back to Me. And Me!
If we go for the implied requirement of VBA to be syntactically fault tolerant then we should expect, if the job has been done correctly, either Me. or Me! to be acceptable.
To that end, I don’t believe VBA can be reasonably compared with any other language. It has a dual roll in that out of the box it’s ready to go, admittedly with a great cringe factor from the purists. But if the purists want to turn Option Explicit on they get a different bucket of bolts altogether.
To that end even Microsoft
may have done VBA a disservice.
The Microsoft DAO 2.5/3.5 Compatibility Library can handle the syntactically fault tolerance of Me. verses Me! whereas the later version of Microsoft DAO 3.6 Object Library can not.
So, if the aim of having Option Explicit default to off, presumably to get the users up and running quickly (syntax fault tolerance) then why was there a
decrease in syntax fault tolerance between the Microsoft DAO 2.5/3.5 Compatibility Library and the later Microsoft DAO 3.6 Object Library? That is a question for Microsoft.
>>It’s just a weekend discussion…<< sounds like a good name for a new technical Forum but, then again, I’m biased.
Chris.