Best Practice on Multiple Variable Names (w/similar purpose) Within Same Call Stack?

[Isaac]

If I have 2 procedures, both with some required parameters, and let's say for whatever reason I've structured them in a way where there is one particular param that essentially has the same meaning & purpose to both procedures. Perhaps we could assume for the purpose of this question, to keep it simple, that there is a good reason for that. But I guess if you have an explanation for why this "ought" never be the case, I'm open to learning that too.

Sub1 does a few things and Sub2 does a few things, but each one of them needs this information - Param1. Therefore, it is a required parameter of both.

1. Are there any guidelines, experience, opinions on naming conventions for that Param1 ? As far as naming them the same, naming them different, or naming them specifically to indicate their hierarchy?
2. Is your suggestion mostly for readability and maintenance, or is something involved that gets impacted with error handling or some other 'hard' result?

Are there any guiding principles here or not really?

 

[The_Doc_Man]

There is no hard-and-fast rule. Within the bounds of personal "artistic license" - a rose by any other name smells as sweet.

My PERSONAL viewpoint is that if the parameter is common to both of these routines, then it has an existence outside them. In that case, it has a function as well. So I name such parameters based on that external function. If that means using the same name for both procedures, fine.

But also remember this: The name you supply as the formal parameter for the subroutine doesn't have to even closely resemble the actual parameter used when calling the sub. You could give it a formal name of George for all anyone cared, and it would work just as well. As long as the variable is of the correct type, any name would work unless you "stepped on" a reserved name.

The one thing I might not do is give the formal parameter the same name as the actual parameter as it appears outside the context of the sub. But that is an "avoid confusion" situation, not a technical issue.

 

[Isaac]

Thank you, good thoughts. I keep vascillating between "having the same name is very confusing", to, "having different names is confusing", which is a weird place to be mentally ha ha.

By your last statement, did you mean, for example, the following is what you'd avoid?

Sub Test(lngInput As Long)
MsgBox lngInput
End Sub

Sub Master()
Dim lngInput As Long    'avoid naming this local var the same as the subproc's formal param
lngInput = 5
Test lngInput
End Sub

 

[MajP]

I am not sure I understand and maybe you could give an example. However, I would think 99% percent of the time when you have like parameters of the same type of information you would have the same name in different procedures. I think I would be confused the other way.

I am trying to think of groups of common functions in VBA.
There are lots of string functions. You pass in a string and that has the name "String" and the start position is always "Start".
There are lots of date functions . You pass in a date and that argument is always "Date"
There are lots of aggregate functions. They all use "Expr", "Domain", "Criteria"

 

[pbaldy]

I don't have an issue with your example. I have a vehicle maintenance app open right now, and I can't tell you how often you'll find lngCarNum declared and used. Lots of public functions have it as an input parameter, and a calling procedure might well also have it declared within just as you have.

Thinking about it, I suppose a case could be made for having a single global variable. Something like:

Public lngInput As Long

Sub Test()
  MsgBox lngInput
End Sub

Sub Master()
  lngInput = 5
  Test
End Sub

 

[Isaac]

I am not sure I understand and maybe you could give an example. However, I would think 99% percent of the time when you have like parameters of the same type of information you would have the same name in different procedures. I think I would be confused the other way.

I am trying to think of groups of common functions in VBA.
There are lots of string functions. You pass in a string and that has the name "String" and the start position is always "Start".
There are lots of date functions . You pass in a date and that argument is always "Date"
There are lots of aggregate functions. They all use "Expr", "Domain", "Criteria"

Well, my current real life scenario is: I have 2 procedures. One 'master' (will call the other) and one 'child' (will be called by master). Both procedures have an input parameter "Stage" and "lngCorrectNumberOfAttachments" because they both work with stuff that needs this.
I was just trying to think of basically how might I be making it harder or easier on myself by either keeping them like that or making them different ... like Stage_master and Stage_child or something. (Imagining troubleshooting and making my Immediate Window life easier or harder - maybe that's what the Locals window is for, I haven't used it that much yet to be honest).

@pbaldy thanks also for the input. Yes, if it gets much thornier than this I might consider just using a global.

 

[Pat Hartman]

Scope is relevant. The vast majority of my variables are defined as Private so their scope is limited to the procedure in which they are defined. Given this, it doesn't make any sense to go out of your way to come up with different names for each procedure. If you need StartDT in multiple procedures, then keep using that name since it will make sense in context and other developers reading the code would understand that the scope of StartDT is local as long as you define it as Private.

However, if the variable is Public and passed to multiple procedures then you would also use the same name every place the variable is referenced. The difference of course is the value of the variable would be the same everywhere if you passed the variable by reference but NOT if you passed it by value. When you pass by reference, a called procedure could modify the public value but if you pass by value, the called procedure cannot modify the public value.

So, If I were passing by reference, the implication is that any procedure could change the value of the Public variable, I would use the same name everyplace but if I were passing by value, I would use the public name in the call but I would give the variable a different name in the procedure header. I would probably use the same "different" name in all the procedures. But always using the same name is fine.

I believe the default in Access is to pass by value because that is the safest option. That keeps subs from ever changing the value in the calling procedure.

So the answer comes down to - YOU must understand the scope of a variable to know whether or not to expect the value to be the same in different procedures.

 

[The_Doc_Man]

I believe the default in Access is to pass by value

Actually, Pat, "by value" is not the default. It is by reference.

Passing arguments efficiently (VBA)

Office VBA reference topic

docs.microsoft.com

 

[Pat Hartman]

I knew there was something about passing variables in Access I didn't like

 

[Isaac]

That's a good point about the scope - I mean even without the byval/byref. In my scenario where I wonder what's the best nomenclature approach, usually everything is private to the local procedure and public/global var's are not coming into play.

I can never remember which (byval/byref) is the Default either--It never matters to me, because in 15 years of doing, I have yet to use anything other than the default.

 

[Pat Hartman]

If one programmer is doing all the development, the byVal, byRef option doesn't matter much since he will be consistent. It's when you have multiple concurrent developers or serial developers with different styles that the option can bite you.

 

[Isaac]

Ok....I just had the most coincidental thing in a LONG time happen to me. It's also a bit humbling, since my last post made it sound like I knew what I was doing, whereas this experience that happened a minute ago proves that I was not quite as far along in understanding this as I thought I was.

Because I thought what happened to me couldn't ever possibly happen!
I cut out a lot of code here, just left in a few crucial aspects.
First procedure:

Sub Master_ProcessAttachmentsFromDistributionPortal(strStage As String, lngCorrectNumberofAttachments As Long, lngStage3or5 As Long)
Dim strDestinationFolder As String

'create our temp folder
strDestinationFolder = Environ("appdata") & "\DistPortalDownload_" & Format(Now, "yyyymmddhhmmss")
MkDir strDestinationFolder

'this saves only attachments from records
SaveAllAttachmentsFromSPToFolder strDestinationFolder, strStage, lngStage3or5

Set fso = CreateObject("scripting.filesystemobject")
Set fsofolder = fso.getfolder(strDestinationFolder)

'sometimes, there aren't any:
If CountFilesInFolder(strDestinationFolder) = 0 Then
    fso.deletefolder (strDestinationFolder)             '**********************************************THIS ERRS, NOT FOUND, B/C CountFilesInFolder added a trailing \
    MsgBox "No files to process", vbInformation, "  "
    Exit Sub
End If


MsgBox "Done"

End Sub

Second procedure:

Function CountFilesInFolder(strDir As String) As Long
Dim file As Variant, i As Integer
If Right(strDir, 1) <> "\" Then strDir = strDir & "\"
file = Dir(strDir)
While (file <> "")
    i = i + 1
    file = Dir
Wend
CountFilesInFolder = i
End Function

So...

1. strDestinationFolder is created as a local variable in the master proc
2. master proc calls a function, which requires strDir to be passed in....master passes strDestinationFolder as the intended value for strDir
3. function takes whatever it got passed in for strDir and ADDS a trailing backslash to strDir
4. now the value of strDestinationFolder is actually different!

So I just learned that somehow all this time I had it backwards. I thought I was defaulting to the 'safer' way, but actually, I was defaulting to the more dangerous way - byRef. This is just the first time I've used this series of events--including a function which alters the value of its passed-in parameter, which I don't ever normally do but this function was from a webpage somewhere.

Ultimate irony: This is what I get for violating my OWN rule that I'm always preaching....the downsides of frequently relying on default values, properties, behavior. Because you end up forgetting the "why" behind the behavior and not learning what needs to be learned. And guess what, the rule is a great one--Unfortunately, I violated it and exactly what I predict, came true--to me.
With this humble pie I may not need to eat the entire weekend, but I am thankful for the experience, as well as the exercise of admitting it LOL