An "Option Explicit" in every module! (Herbert Hoover 1928)

User avatar
ChrisGreaves
PlutoniumLounger
Posts: 15641
Joined: 24 Jan 2010, 23:23
Location: brings.slot.perky

An "Option Explicit" in every module! (Herbert Hoover 1928)

Post by ChrisGreaves »

If I've done it right, the attached, zipped, OptEx.DOT will make sure that each module of a project, or each module of each project of a folder, holds an "OPTion EXplict" statement.
Typical problem for me when overtaking a project that was recorded macros by a novice five years ago, and never set up VBE properly.

As usual, comments and suggestions welcomed
Spoiler
(Please be gentle!)
I dashed this off as a quickie over lunch, and will probably extend it and integrate it into my VBProject Manager
You do not have the required permissions to view the files attached to this post.
He who plants a seed, plants life.

User avatar
Don Wells
5StarLounger
Posts: 689
Joined: 27 Jan 2010, 16:45
Location: Ottawa, Ontario, Canada

Re: An "Option Explicit" in every module! (Herbert Hoover 19

Post by Don Wells »

  • I think that it would be wise to add an error trap which appropriately advises the user, for those instances where the target project does not trust access to the Visual Basic Project.
  • Embedding the test procedure within the function to be tested is a new one on me--providing a moment or three of confusion.
Last edited by Don Wells on 23 Jun 2011, 20:17, edited 1 time in total.
Regards
Don

User avatar
HansV
Administrator
Posts: 78568
Joined: 16 Jan 2010, 00:14
Status: Microsoft MVP
Location: Wageningen, The Netherlands

Re: An "Option Explicit" in every module! (Herbert Hoover 19

Post by HansV »

Trusting access to the Visual Basic project is a user-level setting, not a project-level setting.
But perhaps you meant documents that require a password to access the VB project. That is a project-level setting.
Best wishes,
Hans

User avatar
Don Wells
5StarLounger
Posts: 689
Joined: 27 Jan 2010, 16:45
Location: Ottawa, Ontario, Canada

Re: An "Option Explicit" in every module! (Herbert Hoover 19

Post by Don Wells »

HansV wrote:Trusting access to the Visual Basic project is a user-level setting, not a project-level setting.
But perhaps ...
No Hans, I mistakenly thought that it was a project-level setting. Thank you for the correction.
Regards
Don

User avatar
ChrisGreaves
PlutoniumLounger
Posts: 15641
Joined: 24 Jan 2010, 23:23
Location: brings.slot.perky

Re: An "Option Explicit" in every module! (Herbert Hoover 19

Post by ChrisGreaves »

Don Wells wrote:I think that it would be wise to add an error trap which appropriately advises the user, for those instances where the target project does not trust access to the Visual Basic Project.
Quite so.
I already test for a myriad of excuse in the project manager thingy - locked templates etc. If/When I splice this new effort, suitably generalized (to check for more than "Option Explicit") into the project manager thingy, it will inherit all those tests.
The project manager thingy says, in effect, a VBA project is a VBA project is a VBA project, so once I've ferreted my way into opening an MSOffice file of any particular type (dot, doc, xls, xla, ppt etc) I can do with it what I will in terms of VBA components. Hence I harvest VBA code across a hard drive from many sources.
The front-end - that of winkling a VBA project out of a file, is the tricky part. After that it's just "VBA projects all the way down"!
He who plants a seed, plants life.

User avatar
ChrisGreaves
PlutoniumLounger
Posts: 15641
Joined: 24 Jan 2010, 23:23
Location: brings.slot.perky

Re: An "Option Explicit" in every module! (Herbert Hoover 19

Post by ChrisGreaves »

Don Wells wrote:Embedding the test procedure within the function to be tested is a new one on me--providing a moment or three of confusion.
To my mind it's the only way to go.
Self-testing procedures mean that before I modify a procedure, I can re-test it to make sure it still conforms to the standards I'd set when it was last released.
Next I modify the procedure, and check that it still obeys the standards previously set (i.e. no other code that uses the library procedure should break).
Finally I upgrade the TEST subroutine to add the conditions that precipitated the change, and test that they, too, are satisfied by the modified procedure.
Then it's time to disable-by-ccomment the test procedure and drag it back into its womb.

Please don't think I'm perfect at this, I'm not, but I do catch more errors than other I would.

At the time I write a new utility function I code this:

Code: Select all

Public Function strOnlyNOT(strIn As String, strRef As String) As String
End Function
Then I augment it thus:

Code: Select all

Public Function strOnlyNOT(strIn As String, strRef As String) As String
End Function
Sub TESTstrOnlyNOT()
    Debug.Assert "lpht" = strOnlyNOT("alphabet", "abcde") ' regular use "aabe" of 1st string exist in 2nd string
    Debug.Assert 0 = Len(strOnlyNOT("", "abcde")) ' empty source string yields empty result string, length = 0
    Debug.Assert Len("alphabet") = Len(strOnlyNOT("alphabet", "")) ' empty reference string yields empty result string, length = 0
    Debug.Assert "1" = strOnlyNOT("alphabetand1digit", "abcdefghijklmnopqrstuvwxyz") ' strip digit "1"
End Sub
So, you see, I have written my Acceptance Tests before I start coding the procedure.
If I can't specify Acceptance Tests before I start coding, then I ought not to start coding. That is, if you don't know your goal, how can you know when you've reached your goal?
He who plants a seed, plants life.