Why using Call when its not necessary?
WPCode:'DoSomething is a sub
'Why this:
call DoSomething
'or this:
DoSomething
Printable View
Why using Call when its not necessary?
WPCode:'DoSomething is a sub
'Why this:
call DoSomething
'or this:
DoSomething
Why :
I think it's just a matter of preferences!Code:'Why this
Dim hello as String
'or
Dim hello$
IS the same like, why using a pencil. if you can use a pen. :)
I think it's sometimes easier to see you're calling an outside function (hmm.. that's what I use it for :)) and not just VB code, but as sebs said, it's just a matter of preferences.
and sebs, I use Dim str$ because it's shorter and I think it looks cool :cool:
'Cause you can make changes when you've done something wrong :pQuote:
Why use a pencil if you can use a pen
It aids readability.
Have you ever tried to debug/test/update/evaluate someone elses code....
nightmare.
These little niceties help loads
H.
hmm, dont you need to use the call feature if using api.
I tried to do some functions w.out calling anything and it didnt work. Instead I used the Call and it worked fine.
I wasnt actually calling the function on the form, but writing an if then statement w. api calls.
I agree with Jop!
I agree with Jop & Hollie, it's just easer for another programmer (if your working in a team) to see that you are calling a sub or function and makes his life a bit simpler etc...
Don't forget is you use call you must inclose arguments in brackets "()"
I also agree with Hollie on the readability issue.
One of my more miserable tasks at work is maintaining other peoples code when it is unreadable and difficult to follow. Believe it or not some people don't even indent! I'm begging all you coders to put in comments so I know what you were thinking when you wrote the stuff. I do it and find it actually helps me nut out tricky algorithms :)
Basically, Call makes your source code more organized. When you use call, you enclose your arguments in brackets.
If you omit the Call keyword, you cannot enclose it in brackets, which in some people's opinion is sloppy coding.Code:Call MyFunc(Arg1, 0, 0, 0, 0, &H54)
Code:MyFunc Arg1, 0, 0, 0, 0, &H54
Call uses less memory when calling a function if you don't need the return value (in the case of the api). This is because you don't need to allocate a variable to store the data, as Call discards it.
I'm actually pretty good at reading others' code. I indent all code before trying to figure out what it does. If you have a piece of code that is absolutly unreadable, I can usually decipher it. I decipher other people's code when I get bored with what ever project I'm working on.
I remember that in earlier versions of VB, before Option Explicit, I was never sure that a statement DoSomething was a call to a Sub or just an undeclared variable; whereas Call DoSomething is totally unambiguous.
Adrian.
agent - all the API functions return a value for a good reason. Technically, you should always check for an error code, though very few do.
My personal preferences:
I just don't like seeing Call around, since I've always been used to minimising code length for the sake of readability.Code:Dim x As String
x = MyFunc(10, 10)
MySub 10, 10
Adrian brought up a good point about Option Explicit. Does anyone here always use it? (I do)
Best thing since sliced bread for me. I'm a classic for mis-typing variables. DOH!
Adrian.
minimalist code makes for elegance.
td
Not always, though. Quick C++ example (good for minimising code size):
...can be condensed to:Code:if(i) {
y = 10;
} else {
y = 20;
}
But that doesn't make it any more readable :(.Code:y = i ? 10 : 20;
In my opinion, the Call statement makes code easier to understand.
Call MyFunc(1,2,3,4,5)
rather than:
MyFunc 1,2,3,4,5
Makes it easier to read and understand.
But both ways work the same.
Hi all !!!
I agree with your statements about readable code from
another coder but in all your examples I'am missing that each function or sub call can also be written with named parameter for better reading e.g.
iRet = fktMyfunction (Para1:=1,Para2:=3)
DoSomething Para1:=1,Para2:=3
so in my opinion you didn't need the CALL Statement if you use the naming convention and named parameters.
-cu TheOnly
the trouble with that is that if the reader is unfarmiiar with the calling convention he/she may wonder what iRet is, it's definetley nowhere near as obvious as a big blue call sign, also it probably doesn't matter in most vb apps but if you are going to use a return value you have to declare it which makes the code a little slower, and if you want it to accept more than one data type you have to make it a variant or go throgh conversions, which can slow the code down quite considerably and even cause errors, if you ever need to look at iRet you should really give it a different name so the reader knows what it is. Although it's only a little sloppy as coding practices go if you're writing a time critical or recursive function iRet shouldn't be used. which can mean 2 seperate coding conventions in the same module. unless there is a serious advantage of iRet in your code there's no point using it and it is harmful. So Call is definatley the better option there.