To 'Call' or not to 'Call'

[Guus2005]

I see it in a lot of programs. I never use it. Do we need it and why?

What i am talking about is the "Call" keyword.

Public Sub SomeRoutine()
   ...
End sub

Public Sub Doit()
    Call SomeRoutine
End sub

Public sub WhatIDo()
   SomeRoutine
End Sub

Which is better?

Thanks,

Guus

 

[arnelgp]

Call can be used both on Subs/Function.
If you want to ignore the return value of a Func , you use Call.
I always use Call for clarity that you are calling a sub/func than a plain Subname.

 

[isladogs]

I never use Call either.
Whether 'calling' a function or a button click event, both methods work equally well and I'm not sure either is better.

 

[MajP]

Either way should understand the impacts of using () in either type of call. This causes a lot of confusion, and 99% of the time when people explain it, it is wrong. Here is the best explanation
https://blogs.msdn.microsoft.com/ericlippert/2003/09/15/what-do-you-mean-cannot-use-parentheses/

 

[pbaldy]

I can't take a position on "better", but I never use Call either. I've never heard a reason why it would be better, but perhaps this thread will reveal one.

 

[theDBguy]

Hi. I don't know about being "better" or not either, but I also use Call, like Arnel, to tell myself that I am intentionally ignoring any return value, in that particular case.

 

[Mark_]

Not myself, but another programmer I had worked with uses CALL only for code they've added themselves in another module. Simply a "So I remember its not built in" reminder.

 

[GinaWhipp]

I also use Call on UDF's for clarity.

 

[The_Doc_Man]

I think I recall a discussion similar to the issues noted by MajP in that linked article. Though it is about VB, a lot of it applies to VBA.

I rarely use CALL myself, but every now and then a reason comes up where CALL is appropriate as a visual reminder to make something stand out. I can think of no techie reasons, but there might be a programming-style reason.

 

[JHB]

..
I always use Call for clarity that you are calling a sub/func than a plain Subname.

I use it exactly like arnelgp.

 

[Guus2005]

Even when i call a function of which i dont use the return value i use a dummy variable instead.
Typing a simple Call prefix would be faster.

Thanks for your input everyone!

 

[CJ_London]

Typing a simple Call prefix would be faster.

would think not typing call and not including brackets would be faster

how often do you call msgbox for example?

msgbox "Hello"

v

call msgbox("Hello")

 

[The_Doc_Man]

Seems to me that NOT using the CALL prefix would be faster because of having fewer characters to type. It wouldn't be much faster to execute. In terms of compiler theory, the only difference between CALL xxxx and direct invocation of xxxx is handled at compile time because by execution time, the work is already done. There should be no difference in the resultant code if the compiler allowed the call in the first place (i.e. no syntax errors). Of course we can't know that since we don't get to see the pseudo-code that gets generated by compilation.

If you used CALL rather than invoke a function in a way to store the result in a throwaway value, there should be one extra instruction compiled from the "throwaway" case - the one that stores the returned value. The CALL case for a function ALSO gets back a value but just doesn't store it. You'd never notice the speed difference unless that was a BIG loop.

 

[Pat Hartman]

Old habits die hard. Call was required in COBOL so I still use it.

There is an excellent albeit old book out there called "The Psychology of Computer Programming" by Gerald Weinberg. It is about the human aspect of programming rather than the technical aspect. One of the points it makes is that the best languages are rigid and allow one and only one method of doing something. That puts VBA in the poor category since there are various ways to do many things. But I still love Access

 

[NauticalGent]

But I still love Access

That is obvious to the most casual observer...and it shows!

 

[Dreamweaver]

I don't really use it, but sounds a good idear for the function return value I will use it for the same in future thanks


mick

 

[The_Doc_Man]

Access is OK even though it has automatic type up-conversion within a statement. The one I don't like is old-style C which requires you to run a pre-compiler to catch datatype issues. Classic C allowed you to do abominable things with mixed-mode expressions.

On the other hand, P/L-1 is one of those love to hate/hate to love languages where the typing is SO strict that an 80 character string is NOT the same type as a 79 character string and you have to do explicit typecasts to make them work together. But if you get your code past THAT compiler, you KNOW you don't have any datatype issues. Of course, with typical military logic >>cough, cough, choke<<, the Navy decreed about 15 years ago or so that P/L-1 would be the preferred language for all new software development. Fortunately there were waiver processes for compatibility issues. It was always fun to talk about new programs with the Navy. You never knew quite what would be in the specs, but you just KNEW it wouldn't be easy.