sub or function

[Roland Hall]

I'm tired of getting beat up on this issue so I thought I'd ask what you
some of you think.

I know the basic difference between a subroutine and a function is a
subroutine performs a task and a function performs a task and returns a
value. The Call keyword is required when using parens with subs with more
than 1 parameters. Parens around values passed are ByVal vs ByRef and is a
waste of processing if passed ByRef for no reason.

I am told there is no reason to ever use a subroutine as a function can be
used even if it doesn't return a value. While this appears to be true, is
there any reason why it's ever a bad idea to use a function, instead of a
subroutine, that doesn't return a value? Are there memory, performance,
etc. issues?

TIA...

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Curt_C [MVP]]

I'm tired of getting beat up on this issue so I thought I'd ask what you
some of you think.

I know the basic difference between a subroutine and a function is a
subroutine performs a task and a function performs a task and returns a
value. The Call keyword is required when using parens with subs with more
than 1 parameters. Parens around values passed are ByVal vs ByRef and is a
waste of processing if passed ByRef for no reason.

I am told there is no reason to ever use a subroutine as a function can be
used even if it doesn't return a value. While this appears to be true, is
there any reason why it's ever a bad idea to use a function, instead of a
subroutine, that doesn't return a value? Are there memory, performance,
etc. issues?

TIA...

There may be some perf loss but these days I doubt you would notice...
Best answer is, almost always, do what you feel comfortable with as long
as it does what you need it to.....

 

[Bob Barrows [MVP]]

I'm tired of getting beat up on this issue so I thought I'd ask what
you some of you think.

Somebody's beating you up about this ... ??

I am told there is no reason to ever use a subroutine as a function
can be used even if it doesn't return a value. While this appears to
be true, is there any reason why it's ever a bad idea to use a
function, instead of a subroutine, that doesn't return a value? Are
there memory, performance, etc. issues?

As far as performance is concerned, I think Eric says it best:
http://blogs.msdn.com/ericlippert/archive/2003/10/17/53237.aspx

The whole "function vs sub" controversy seems to have devolved into a
religious debate, much like the top-posters vs. inline posters...

Back in the day of VB3, using a sub instead of a function might have made a
difference as far as memory or performance is concerned. Nowadays, it's
really just personal preference.

Bob Barrows

 

[Roland Hall]

in message
: Roland Hall wrote:
: > I'm tired of getting beat up on this issue so I thought I'd ask what
: > you some of you think.
:
: Somebody's beating you up about this ... ??

Two people actually because of what I said to someone else regarding their
style of coding

Call somefunction(param1, param2)

: > I am told there is no reason to ever use a subroutine as a function
: > can be used even if it doesn't return a value. While this appears to
: > be true, is there any reason why it's ever a bad idea to use a
: > function, instead of a subroutine, that doesn't return a value? Are
: > there memory, performance, etc. issues?
: >
:
: As far as performance is concerned, I think Eric says it best:
: http://blogs.msdn.com/ericlippert/archive/2003/10/17/53237.aspx
:
: The whole "function vs sub" controversy seems to have devolved into a
: religious debate, much like the top-posters vs. inline posters...

Is vbs now to be thought of as jscript where everything is a function?

: Back in the day of VB3, using a sub instead of a function might have made
a
: difference as far as memory or performance is concerned. Nowadays, it's
: really just personal preference.

Are you stating there is not difference other than one can return a value?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Roland Hall]

"Curt_C [MVP]" <software_at_darkfalz.com> wrote in message
: Roland Hall wrote:
: > I'm tired of getting beat up on this issue so I thought I'd ask what you
: > some of you think.
: >
: > I know the basic difference between a subroutine and a function is a
: > subroutine performs a task and a function performs a task and returns a
: > value. The Call keyword is required when using parens with subs with
more
: > than 1 parameters. Parens around values passed are ByVal vs ByRef and
is a
: > waste of processing if passed ByRef for no reason.
: >
: > I am told there is no reason to ever use a subroutine as a function can
be
: > used even if it doesn't return a value. While this appears to be true,
is
: > there any reason why it's ever a bad idea to use a function, instead of
a
: > subroutine, that doesn't return a value? Are there memory, performance,
: > etc. issues?
: >
: > TIA...
: >
:
: There may be some perf loss but these days I doubt you would notice...

Would that unnoticeable difference be relevant if there were hundreds or
thousands of users?

: Best answer is, almost always, do what you feel comfortable with as long
: as it does what you need it to.....

I try but the law keeps responding with, "She must be at least 18!"

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Bob Barrows [MVP]]

in message


Is vbs now to be thought of as jscript where everything is a function?

I don't think I said that.

It CAN be thought of that way. It doesn't have to be. I still use subs
extensively, I'm accustomed to them - it's mainly a matter of style.

Are you stating there is not difference other than one can return a
value?

Yeah, pretty much. The slight overhead involved in creating the memory space
to contain the returned value (in the case of functions) is avoided when
using a sub. And at some time in the past, perhaps that difference may have
noticeable in VB. But not with today's machines. And definitely not with
vbscript which has many more performance issues than using subs vs
functions.

There is one advantage to using functions: with a function, you can return a
boolean to indicate the success/failure of the procedure. With a sub, you
either have to raise an error or use an extra ByRef argument to let the
calling procedure know about the sub's outcome. Raising errors definitely
definitely has a performance impact: much more than using a function instead
of a sub.

Also, using functions exclusively will make the transition to jscript or C#
a little easier (not much, but a little).

Bob Barrows

 

[CJM]

The only thing I can add to Bob's post is that one advantage of using both
Subs & Functions is that there is a little greater clarity. You can expect a
return from a Function but not from a Sub, so it's arguably a little easier
to debug - you know what to expect. Ok, it's not the greatest advantage, but
it can help!

CJM

 

[Roland Hall]

in message : The only thing I can add to Bob's post is that one advantage of using both
: Subs & Functions is that there is a little greater clarity. You can expect
a
: return from a Function but not from a Sub, so it's arguably a little
easier
: to debug - you know what to expect. Ok, it's not the greatest advantage,
but
: it can help!

Well, I thought there was a memory issue although negligible, it increases
with each concurrent user. I see no reason to waste memory just because I
can. And you stated it as I use them to know a sub is not going to return a
value and a function will return one so it IS easier to read and debug, at
least for me.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Roland Hall]

in message
: Roland Hall wrote:
: > "Bob Barrows [MVP]" wrote in message
: > : >> Roland Hall wrote:
: >>
: >> The whole "function vs sub" controversy seems to have devolved into a
: >> religious debate, much like the top-posters vs. inline posters...
: >
: > Is vbs now to be thought of as jscript where everything is a function?
:
: I don't think I said that.

Ok, but if your nose starts to grow...

: It CAN be thought of that way. It doesn't have to be. I still use subs
: extensively, I'm accustomed to them - it's mainly a matter of style.

Outside of mainly...?

: >> Back in the day of VB3, using a sub instead of a function might have
: >> made a difference as far as memory or performance is concerned.
: >> Nowadays, it's really just personal preference.

See the first question.

: > Are you stating there is not difference other than one can return a
: > value?
:
: Yeah, pretty much. The slight overhead involved in creating the memory
space
: to contain the returned value (in the case of functions) is avoided when
: using a sub. And at some time in the past, perhaps that difference may
have
: noticeable in VB. But not with today's machines. And definitely not with
: vbscript which has many more performance issues than using subs vs
: functions.

So, this is still no longer an issue in VB either?

: There is one advantage to using functions: with a function, you can return
a
: boolean to indicate the success/failure of the procedure. With a sub, you
: either have to raise an error or use an extra ByRef argument to let the
: calling procedure know about the sub's outcome. Raising errors definitely
: definitely has a performance impact: much more than using a function
instead
: of a sub.
:
: Also, using functions exclusively will make the transition to jscript or
C#
: a little easier (not much, but a little).

Transition to jscript? Do you know something? Is everything VB related
going away?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Bob Barrows [MVP]]

in message


Ok, but if your nose starts to grow...
Why?


Outside of mainly...?
Huh?

See the first question.

Why? How can this be translated into "Is vbs now to be thought of as jscript
where everything is a function?"
Maybe I'm misinterpreting that question ... the phrase "to be thought of"
has overtones of "must be thought of". Did you mean it that way? Or did you
mean it more like "can vbs be thought of ... "?

So, this is still no longer an issue in VB either?

Since VB is compiled, then yes, it may be more of an issue in VB than in
vbscript. However, there are likely to be many more things to worry about
than this, even in VB. It's a little harder to write an application without
subs in VB because all the generated event handlers are created as subs.

Transition to jscript? Do you know something? Is everything VB
related going away?

Nope, you've read a little too much into my statement. I should have said:
"IF you are going to learn another language such as jscript, C#, etc., then
the transition will be slightly easier ... "

Bob

 

[!TG]

I'm tired of getting beat up on this issue so I thought I'd ask what you
some of you think.

I know the basic difference between a subroutine and a function is a
subroutine performs a task and a function performs a task and returns a
value. The Call keyword is required when using parens with subs with more
than 1 parameters. Parens around values passed are ByVal vs ByRef and is a
waste of processing if passed ByRef for no reason.

I am told there is no reason to ever use a subroutine as a function can be
used even if it doesn't return a value. While this appears to be true, is
there any reason why it's ever a bad idea to use a function, instead of a
subroutine, that doesn't return a value? Are there memory, performance,
etc. issues?

TIA...

Subs will change values of preexisting variables if you use the same
generic variables by habit.
Depending on the purpose, this can be an advantage or trouble.

I personally use Subs for mostly simple display tasks and functions for
more complicated work.

 

[Roland Hall]

in message
: Roland Hall wrote:
: > "Bob Barrows [MVP]" wrote in message
: > : >> Roland Hall wrote:
: >>> "Bob Barrows [MVP]" wrote in message
: >>> : >>>> Roland Hall wrote:
: >>>>
: >>>> The whole "function vs sub" controversy seems to have devolved
: >>>> into a religious debate, much like the top-posters vs. inline
: >>>> posters...
: >>>
: >>> Is vbs now to be thought of as jscript where everything is a
: >>> function?
: >>
: >> I don't think I said that.
: >
: > Ok, but if your nose starts to grow...
:
: Why?

I said, IF.

: >> It CAN be thought of that way. It doesn't have to be. I still use
: >> subs extensively, I'm accustomed to them - it's mainly a matter of
: >> style.
: >
: > Outside of mainly...?
:
: Huh?

If it's mainly a matter of style, what else matters?

: >>>> Back in the day of VB3, using a sub instead of a function might
: >>>> have made a difference as far as memory or performance is
: >>>> concerned. Nowadays, it's really just personal preference.
: >
: > See the first question.
:
: Why? How can this be translated into "Is vbs now to be thought of as
jscript
: where everything is a function?"
: Maybe I'm misinterpreting that question ... the phrase "to be thought of"
: has overtones of "must be thought of". Did you mean it that way? Or did
you
: mean it more like "can vbs be thought of ... "?

'can' could probably work but probably my meaning was 'should'
Should I just use functions and eliminate the use of subs in vbscript?
(remove the arguments for readability and negligible memory loss)

: >>> Are you stating there is not difference other than one can return a
: >>> value?
: >>
: >> Yeah, pretty much. The slight overhead involved in creating the
: >> memory space to contain the returned value (in the case of
: >> functions) is avoided when using a sub. And at some time in the
: >> past, perhaps that difference may have noticeable in VB. But not
: >> with today's machines. And definitely not with vbscript which has
: >> many more performance issues than using subs vs functions.
: >
: > So, this is still no longer an issue in VB either?
:
: Since VB is compiled, then yes, it may be more of an issue in VB than in
: vbscript. However, there are likely to be many more things to worry about
: than this, even in VB. It's a little harder to write an application
without
: subs in VB because all the generated event handlers are created as subs.

This is the type of answer I was looking for. I guess you're saying
vbscript doesn't have requirements like this.

: > Transition to jscript? Do you know something? Is everything VB
: > related going away?
: >
: Nope, you've read a little too much into my statement. I should have said:
: "IF you are going to learn another language such as jscript, C#, etc.,
then
: the transition will be slightly easier ... "

Nah, I was just yanking your chain on this question. Wonder how many MSFT
emps read it and said, "Ya', what has he heard?" or "Aw crap! Cats outta'
the bag."

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Roland Hall]

in message : Roland Hall wrote:
: > I'm tired of getting beat up on this issue so I thought I'd ask what you
: > some of you think.
: >
: > I know the basic difference between a subroutine and a function is a
: > subroutine performs a task and a function performs a task and returns a
: > value. The Call keyword is required when using parens with subs with
more
: > than 1 parameters. Parens around values passed are ByVal vs ByRef and
is a
: > waste of processing if passed ByRef for no reason.
: >
: > I am told there is no reason to ever use a subroutine as a function can
be
: > used even if it doesn't return a value. While this appears to be true,
is
: > there any reason why it's ever a bad idea to use a function, instead of
a
: > subroutine, that doesn't return a value? Are there memory, performance,
: > etc. issues?
: >
: > TIA...
: >
:
: Subs will change values of preexisting variables if you use the same
: generic variables by habit.
: Depending on the purpose, this can be an advantage or trouble.

Are you saying a passed variable to a sub, if the value changes will change
the value of a global variable? Isn't that only true if it's passed ByRef?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[CJM]

Are you saying a passed variable to a sub, if the value changes will
change
the value of a global variable? Isn't that only true if it's passed
ByRef?

From MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/vsstmsub.asp

"Variables used in Sub procedures fall into two categories: those that are
explicitly declared within the procedure and those that are not. Variables
that are explicitly declared in a procedure (using Dim or the equivalent)
are always local to the procedure. Variables that are used but not
explicitly declared in a procedure are also local, unless they are
explicitly declared at some higher level outside the procedure.

Caution A procedure can use a variable that is not explicitly declared in
the procedure, but a naming conflict can occur if anything you have defined
at the script level has the same name. If your procedure refers to an
undeclared variable that has the same name as another procedure, constant or
variable, it is assumed that your procedure is referring to that
script-level name. To avoid this kind of conflict, use an Option Explicit
statement to force explicit declaration of variables."

I'm not sure this quote entirely answers the question, but it was
interesting anyway. But as I see it, if you pass a Global variable ByVal it
is treated as a local variable; if you pass it ByRef, any changes are
reflected in the calling procedure - which means that if the variable had
Global scope it would be changed throughout the application. Which I'm
guessing was you original understanding?

However, if you were talking about a Global variable, there would be no
reason to pass it as a parameter because it already accessible because it
is...er.. Global!

I hope this hasn't muddied the water any further!

Chris

 

[Bob Lehmann]

Isn't that only true if it's passed ByRef?
The default is ByRef in VBScript. So, unless you you explicitly pass it
ByVal, it will be changed.

Bob Lehmann

 

[Roland Hall]

:
: : >
: > Are you saying a passed variable to a sub, if the value changes will
: > change
: > the value of a global variable? Isn't that only true if it's passed
: > ByRef?
:
: However, if you were talking about a Global variable, there would be no
: reason to pass it as a parameter because it already accessible because it
: is...er.. Global!
:
: I hope this hasn't muddied the water any further!

No problem.

What if it is passed from another sub/function?

function myincfunc(x)
myincfunc= x + 1
end function

sub tomorrow(x)
dim thisday, nextday
thisday = x
nextday = myincfunc(thisday)
Response.Write "Tomorrow's secret number is: " & nextday
end sub

dim x
x = 4
tomorrow x

x is global
sub x is byRef, assigned byVal to thisday, passed byRef to func x,
incremented and returned

Did any initial variables change?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Roland Hall]

in message : >> Isn't that only true if it's passed ByRef?
: The default is ByRef in VBScript. So, unless you you explicitly pass it
: ByVal, it will be changed.

I know it [global variable] changes because I've been caught with my pants
down on this issue before and had to use ByVal to get out of it but it was a
global variable I was passing, which was not required. A local variable
will also change if passed byRef to another sub/function?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[CJM]

Problem spotted - I'm an idiot.

Of course, when we run test1() it is updating the variable y.

Modified code:

<%@ Language="VBScript" %>
<%

Option Explicit

Dim x

function test1(x)
x = x + 10
test1 = x
End function

function test2()
x = x + 1
test2 = x
end function

sub test0()
dim y, z

y = x

z = test1(y)

response.Write "Test1.1: " & z & "<br>"
response.Write "x = " & x & "<br>"
response.Write "y = " & y & "<br>"

z = test1(y)

response.Write "Test1.2: " & z & "<br>"
response.Write "x = " & x & "<br>"
response.Write "y = " & y & "<br>"

z = test2()

response.Write "Test2.1: " & z & "<br>"
response.Write "x = " & x & "<br>"
response.Write "y = " & y & "<br>"

z = test2()

response.Write "Test2.2: " & z & "<br>"
response.Write "x = " & x & "<br>"
response.Write "y = " & y & "<br>"
end sub

x = 0

response.Write "Pass1: <br>"
test0()

response.Write "<br>Pass2: <br>"
test0()
%>

 

[Chris Hohmann]

A local variable
will also change if passed byRef to another sub/function?

Yes.

<%
Option Explicit
Function Foo(parameter_by_ref)
Dim return_value, local_variable
local_variable = parameter_by_ref
return_value = Bar(local_variable)
Foo = local_variable
End Function

Function Bar(parameter_by_ref)
parameter_by_ref = parameter_by_ref + 1
Bar = "Hello World"
End Function

Response.Write Foo(4)
%>

 

[Chris Hohmann]

What if it is passed from another sub/function?

function myincfunc(x)
myincfunc= x + 1
end function

sub tomorrow(x)
dim thisday, nextday
thisday = x
nextday = myincfunc(thisday)
Response.Write "Tomorrow's secret number is: " & nextday
end sub

dim x
x = 4
tomorrow x

x is global
sub x is byRef, assigned byVal to thisday, passed byRef to func x,
incremented and returned

Did any initial variables change?

AFAIK...

The x in myincfunc is local to the function - it is not the same as the
global variable x. So in this instance the global variable x does not
change.

If we change the function to:

function myincfunc()
myincfunc= x + 1
end function

...so there is no incoming parameter, x the global variable x would be
incremented each time the function is called.

[10 minute interlude...]

Right! I've created a test page. It kind of proved what I was saying with
one exception which I dont understand!

Here's the code:

<%@ Language="VBScript" %>
<%

Option Explicit

Dim x

function test1(x)
x = x + 10
test1 = x
End function

function test2()
x = x + 1
test2 = x
end function

sub test0()
dim y, z

y = x

z = test1(y)

response.Write "Test1.1: " & z & "<br>"
response.Write "x = " & x & "<br>"

z = test1(y)

response.Write "Test1.2: " & z & "<br>"
response.Write "x = " & x & "<br>"

z = test2()

response.Write "Test2.1: " & z & "<br>"
response.Write "x = " & x & "<br>"

z = test2()

response.Write "Test2.2: " & z & "<br>"
response.Write "x = " & x & "<br>"
end sub

x = 0

response.Write "Pass1: <br>"
test0()

response.Write "<br>Pass2: <br>"
test0()
%>

And here are my results:

Pass1:
Test1.1: 10
x = 0
Test1.2: 20
x = 0
Test2.1: 1
x = 1
Test2.2: 2
x = 2

Pass2:
Test1.1: 12
x = 2
Test1.2: 22
x = 2
Test2.1: 3
x = 3
Test2.2: 4
x = 4

It all behaves as I would expect, except for test 1.2. In these cases, I
would expect the returned result to be the same as Test1.1 UNLESS the
global variable x is indeed being updated. However, we can see from the
next line that x only appears to be updated by the test2 function.

3 Possibilities:
- A Bug: possible but doubtful
- A ****-up in my code: usually very likely
- Correct behaviour though for unknown reasons: is this the case?


Any thoughts?

Chris

Everything is behaving as it should. In test 1.1 the a _reference_ to the
local y variable in test0 is being passed to the test1 function. Since it's
a reference, the local y variable in test0 gets incremented to 10. When the
local y variable is pass by _reference_ to the test1 function for a second
time in test 1.2, it is again incremented by 10, resulting in a value of 20.
Basically, all parameters, regardless of scope, are passed by reference
unless explicitly told otherwise.