Is ByRef Necessary

[Hackster]

Is it my understanding that parameters are, by default, passed ByRef. So, with that in mind, why do some people actually type in ByRef?

Example:

Private Sub Whatever(ByRef strString As String)

'is exactly the same as
Private Sub Whatever(strString As String)

Correct?

 

[gmmastros]

I am one of those people that always uses ByRef in the parameter (unless it's byval). I'm kinda finicky about it too.

I find that including ByRef removes ambiguity for other programmers who look at my code.

By getting in to the habit of typing byref or byval, you are forced to think about the parameter and whether the contents will be modified within the proceure.

When creating a parameter, you should be thinking about many different things. What should the name of the parameter be? A good name is important. You should also think about the data type (if you omit the As <DataType> then Variant is assumed). And you should think about whether the value should be modified in the procedure or not.

Hope this helps.

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[Hackster]

Thank you for your response. It probably is a good habit to get into. However, my question remains: If you are going to pass a parameter byref, then you don't have to do anything but create the parameter, right? You do not explicitly need to type in ByRef, correct?

 

[BobRodes]

<You do not explicitly need to type in ByRef, correct?
That is indeed correct. People usually don't specify ByRef, and it probably is a good idea to do so. However, it's also true that this is a generally known default, and that it doesn't do a great deal to clarify your code to someone maintaining it, unless there is a particular reason that you want to point out that you're not passing ByVal. Which is perhaps just a way of saying that I, personally, don't religiously specify ByRef in my code, although maybe I should.

More potentially confusing defaults are things like the default property of text boxes and labels; it's more typical that you will see things like txtMyBox.Text and lblMyLabel.Caption, as opposed to txtMyBox and lblMyLabel. At least, I never rely on default properties.

Also, I prefer to put the variable that I'm using to increment in the Next statement, to avoid confusion there:

For i = 0 to 10
    'do stuff
Next i

HTH

Bob

 

[Hackster]

Thank you both.

That clarifies, at least in my mind, my question.

 

[DrJavaJoe]

Now that everyone is used to ByRef being the default MS goes and changes the default to ByVal in VB.net


Two strings walk into a bar. The first string says to the bartender: 'Bartender, I'll have a beer. u.5n$x5t?*&4ru!2[sACC~ErJ'. The second string says: 'Pardon my friend, he isn't NULL terminated'.

 

[BobRodes]

LOL That's why we get to charge so much money for our time.

Bob

 

[earthandfire]

Surely ByVal is the safer default and can avoid difficult to track bugs. Specifying ByVal or ByRef is always the better approach and means that any changes Microsoft may make are irrelevant.

Hope this helps.

 

[bjd4jc]

>>Now that everyone is used to ByRef being the default MS goes and changes the default to ByVal in VB.net

At least with the VS.NET IDE it is specified for you if you leave it off (at least with the options I use), thus making it less confusing (at least to me).

 

[DrJavaJoe]

bjd4jc, I agree the VS.net IDE has a ton of very nice features.


Two strings walk into a bar. The first string says to the bartender: 'Bartender, I'll have a beer. u.5n$x5t?*&4ru!2[sACC~ErJ'. The second string says: 'Pardon my friend, he isn't NULL terminated'.

 

[chiph]

I always specified ByRef or ByVal when I wrote my functions -- it made it explicit to the person that will be maintaining my code that I expect it to change during the method call.

Remember, 80% of the cost in software is in the maintenance, so making their job easier is a "win".

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[BobRodes]

You make a good point, chip, and I completely share your point of view about the cost of maintainence overhead. Either I'm a bit lazy about this particular thing, or feel that this particular thing is sufficiently well known that it kind of goes without saying. Or maybe both. I certainly wouldn't disagree with your approach.

Bob

 

[Ed2020]

I can certainly see why MS have switched to ByVal as a default. ByVal is more efficient (although it seems counterintuitive as a copy of the variable is produced rather than a pointer to the initial one). ByVal is also generally safer as you cannot inadvertently alter the value of your initial value. ByVal as a default also makes VB more consistent with C++.

In VB6 if you do not specify ByVal or ByRef does not necessarily mean the arguments will always be passed ByRef. If memory serves it depends on the syntax you use to call the routine:

Call MySub(MyName, MyAge)

is different to:

MySub MyName, MyAge

So explicitly specifying ByVal or ByRef also means that, if different developers use your code, the arguments will *always* be passed in the same manner. Personally I always use ByRef unless I have a good reason not to.

Ed Metcalfe.


Please do not feed the trolls.....

 

[strongm]

Secondly

Call MySub(MyName, MyAge)
and
MySub MyName, MyAge

are the same

It is

Call MySub(MyName)
and
MySub (MyName)

which are not (and this is nothing to do with the use of ByRef or ByVal in MySub's declaration))

 

[Ed2020]

I stand corrected.

Please do not feed the trolls.....

 

[BobRodes]

To expand on strongm's comment, the latter syntax forces the argument to be passed ByVal, no matter what the declaration specifies. The equivalent syntax using the Call statement would be

Call MySub((MyName))