To Use Call() or Not to Use Call()

In VB.NET, using Call() is not required when call functions. However, what are good reasons to use Call() and good reasons not to use Call()?
LVL 9
GivenRandyAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Arthur_WoodCommented:
as far as I am aware, thre is NO good reason to use

Call Function

That syntax is VERY OLD, and makes your code Very difficult to read.

Private Sub ThisIsMyProcedure(Value1 as String, Value2 as Integer)
    '  some code here
End SUb

Call ThisIsMyProcedure("ABC", 2)

or

ThisIsMyProcedure("ABC", 2)

personally, I find the seconf style easier to read and understand.

AW

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
eventprostrategiesCommented:
it makes no difference, whatsoever.  "Call" is just outdated.

Public Sub foo2()
        Dim x As Boolean
        Call foo1(x)
End Sub

Public Sub foo3()
        Dim x As Boolean
        foo1(x)
End Sub

turn into ...

.method public instance void  foo2() cil managed
    {
      // Code size       11 (0xb)
      .maxstack  2
      .locals init ([0] bool x)
      IL_0000:  nop
      IL_0001:  ldarg.0
      IL_0002:  ldloc.0
      IL_0003:  callvirt   instance void Project1.Class1::foo1(bool)
      IL_0008:  nop
      IL_0009:  nop
      IL_000a:  ret
    } // end of method Class1::foo2

    .method public instance void  foo3() cil managed
    {
      // Code size       11 (0xb)
      .maxstack  2
      .locals init ([0] bool x)
      IL_0000:  nop
      IL_0001:  ldarg.0
      IL_0002:  ldloc.0
      IL_0003:  callvirt   instance void Project1.Class1::foo1(bool)
      IL_0008:  nop
      IL_0009:  nop
      IL_000a:  ret
    } // end of method Class1::foo3

----

IL_0003:  callvirt   instance void Project1.Class1::foo1(bool) =  IL_0003:  callvirt   instance void Project1.Class1::foo1(bool)

It's more conventional NOT to use Call with .Net
ptakjaCommented:
I disagree with both the previous posts. Personally, I prefer the Call statement as when I am reading code it is crystal clear that a subroutine is being called. There is no abiguity. In addition, if "Calling" a function, it is obvious that the function's return value is ignored when preceded by a Call statement.

Bottom line is that it boils down to a personal preference. As eventprostrategies  pointed out, there is no performance gain one way or the other.
Angular Fundamentals

Learn the fundamentals of Angular 2, a JavaScript framework for developing dynamic single page applications.

Erick37Commented:
In VB6, you would use Call so that you could wrap the args in parentheses.  It was easier to read that way.

VB6 code:
Call MyFunction(Arg1, Arg2, Arg3)
or
MyFunction Arg1, Arg2, Arg3

In .NET, the parentheses are required...
MyFunction(Arg1, Arg2, Arg3)
doobdaveCommented:
I agree with ptakja,

As has been said, there is no performance gain from using or not using Call.

However, I certainly find code much more readable when Call is used, as you can immediately see that you are calling a Sub, or discarding a return value from a Function (the latter I think is a bad practice, as I was taught to ALWAYS asign the return value of a function to a variable, even if you do not ever use that value. In the future, you may find you want to look at the return value, thus making code more maintainable and scalable).

I don't understand how someone can say that using Call makes code LESS readable, as you then have no distinction at all between calling a Sub, and calling a Function.

Ultimately, it's down to personal preference, but bear in mind the comments posted here when you decide whether to use it or not.

HTH.

Regards,

David
RogerSTHLMCommented:
IMHO I'm pleased "call" nowadays is optional. I never use it.

doobdave,
You state you use "call" because you want to make a clear difference between a sub and a function. Personal I see your point but disagree... To me, I think that's quite unimportant for the caller. It's up to the implemented method. I see it the way c# is build. There, there's no difference between a sub and a function. They both do some work a return somehting. In c# you return void to return nothing at all - sub in vb.net. I like this approach better. But - as stated from all of you - it's just a matter of taste and how you "see" the diff between sub and function.

Cheers
R

Bob LearnedCommented:
Calls to subs/functions are required to have parentheses, so the "Call" keyword, which is a VB6 relic that I have always disliked, is even more unnecessary now.

Bob
Joe_GriffithCommented:
It really boils down to this:  Real men use call, sissies don't.
Bob LearnedCommented:
@Joe_Griffith:
Thems fightin' words :)

Bob
ptakjaCommented:
You said it Joe_Griffith. LOL!
RogerSTHLMCommented:
Damn! I belong to the sissies! ;)
Bob LearnedCommented:
<Quote movie="Magnum Force">
  A man's got to know his limitations.
</Quote>

Bob
doobdaveCommented:
lol @Bob
GivenRandyAuthor Commented:
Personally, I haven't used Call() in probably a decade. I prefer to not clutter things with extra text and with VB.NET it is even less useful (like pointed out above). I asked because I have seen a resurgence of the Call() recently in books and magazines. I was confused as to why that was and I thought maybe I was missing something. ;)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic.NET

From novice to tech pro — start learning today.