You make a good point. The difference really is miniscule and MAY only be
felt in a complex environment: many arguments, complex arguments such as
arrays and pointers, etc., resource-intensive processes running concurrently,
and so on. Even then, I’d concede that you’d be hard pressed to find a
difference in performance. But that’s not really what it’s about. It goes
against best practices. Philosophically: Why call a procedure to call a
procedure? Whether the hit is felt in performance or not, it most definitely
is another layer of processing, and, as such, it is wasteful. Even if only
philosophically.
I've heard the argument for documentation, but here are some points about
that: There are better ways to document things than with a call that makes a
call to a call. You could use ‘^ for sub procedure calls and, let’s say, ‘^^
for function calls:
MyProc ‘^
MyFunc() ‘^^
Either of which should stand out better than the word Call. Besides, what's
really the point of documenting a call? If there is a point, then why not
come up with any combination of symbols to represent other types of
statements? Why document just calls, after all? Why not also document
assignments, branches, etc.? We usually document processes; we don't usually
point out: "This is a call, this is a function, this is a branch." When we
document code, it is to point out what happens when, what the logic is behind
what we're doing, and so on. Besides, really, with practice you learn to spot
the sub procedure calls as easily as with a call to Call, or as easily as you
spot function calls. Or assignments, branches, etc.
In almost all cases, the Call statement makes no unique contribution. It
offers no added value and is philosophically bizarre. It is thus silly (no
offense meant to anyone). There is one case in which the Call statement makes
sense. And that’s when you want to discard the return value of a function.
Call MyFunc()
will run the function as if it were a sub procedure and the return value
will be ignored. This is the only instance where Call actually has something
unique and justifiable to contribute.
I realize all this may seem very anal to a lot of people, but I do believe
that the philosophy you employ in your coding will end up reflecting in a lot
of places: Elegance (simplicity + functionality), efficiency, clarity,
consistency, etc., all of which ultimately add up to make better programs.
Peter
