Question

I have several procedures that use the FileSystemObject. I find it’s quite convenient.

Question: Is it sensible to pass an existing instance of FileSystemObject from a “main” procedure to these other procedures as an argument, rather than having each procedure create its own instance of FileSystemObject?

Example: is it better in any way to do this:

Sub MainSub()
    Dim FSO : Set FSO = CreateObject("Scripting.FileSystemObject")
    Call OtherSub(FSO, myargs)
    ' call other subs and functions that use FileSystemObject
End Sub

Sub OtherSub(FSO, myargs)
    ' Do stuff with FSO
    ' call other subs and functions that use FileSystemObject
End Sub 

which I have seen at least one programmer do, rather than the following, which is what I usually do:

Sub MainSub()
    Dim FSO : Set FSO = CreateObject("Scripting.FileSystemObject")
    Call OtherSub(myargs)
    ' call other subs and functions that use FileSystemObject
End Sub

Sub OtherSub(myargs)
    Dim FSO : Set FSO = CreateObject("Scripting.FileSystemObject")
    Call OtherSub(myargs)
    ' Do stuff with FSO
    ' call other subs and functions that use FileSystemObject
End Sub 

I can see the idea of doing the former in that this potentially reduces the overhead associated with having multiple instances of FileSystemObject. But it seems terribly cumbersome to have to pass FSO as an argument each time. And seriously, is the overhead really that big?

Answer 1

In my opinion the overhead of creating many FSOs is not the problem; but “you should not repeat yourself” and each CreateObject( "System.FileSystemObject" ) [oops] increases the risk of a run time error. Under the hood there is exactly one file system and one file system object, so if C/C++ programmers are allowed to use STDOUT or cerr, a VBScript/VBA programmer has the right to a global FSO (you can’t do anything to a singleton FSO that changes its workings in other subs/functions – except zapping the holding variable).