Visual Basic, M = Design(x,y,z) /vs/ Design x,y,z

M = Design(x,y,z) /vs/ Design x,y,z

Author	Message
G. Douce #1 / 8	M = Design(x,y,z) /vs/ Design x,y,z I have been creating a lot of functions for which I don't require a return value. Then I thought it would probably be much faster to define these procedures as a sub instead of a function. But the syntax looks kind'of strange: Design x,y,z as opposed to M = Design(x,y,z) Do many people use subs? I imagine it should be faster. Is it poor programming style? G.Doucet
Thu, 29 Aug 2002 03:00:00 GMT

Mian #2 / 8	M = Design(x,y,z) /vs/ Design x,y,z I use public subs quite frequently - particularly for procedures that are likely to be used from various places withing the program. eg. A log graph for a program of mine is used from about 6 different places. I have also read a recommendation to keep procedures as short as possible. This is helped by including public subs - can also make debugging easier. Mianne. Quote: >\| I have been creating a lot of functions for which I don't require a >\| return value. Then I thought it would probably be much faster to define >\| these procedures as a sub instead of a function. >\| >\| But the syntax looks kind'of strange: >\| Design x,y,z >\| as opposed to >\| M = Design(x,y,z) >\| >\| Do many people use subs? I imagine it should be faster. Is it poor >\| programming style? >\| G.Doucet >\| >\|
Thu, 29 Aug 2002 03:00:00 GMT

RobSmit #3 / 8	M = Design(x,y,z) /vs/ Design x,y,z VB _is_ bizarre in the way it switches the use of brackets depending on whether or not you are using the return value from a procedure, but that's just one of the little pecadillos of the language we all love ;-) Sure, if your procedure has no return value it's totally correct to define it as a Sub. If it returns 1 value it's better to make it a function, as this can be used in an expression. If it returns 2 values it has to return at least one of them as a parameter, so it's largely a matter of style whether you use a function with 1 parameter or a Sub with 2 parameters. Don't forget that a procedure defined as a function can still be called as though it was a Sub: Design x,y,z ignoring the return value- there is a case for defining almost all procedures as functions, returning some value (say a success flag) that the caller can choose to ignore. Oh, glad you don't use Call- it's so ugly! (stand by those extinguishers! :-) -- RobSmith Quote: > I have been creating a lot of functions for which I don't require a > return value. Then I thought it would probably be much faster to define > these procedures as a sub instead of a function. > But the syntax looks kind'of strange: > Design x,y,z > as opposed to > M = Design(x,y,z) > Do many people use subs? I imagine it should be faster. Is it poor > programming style? > G.Doucet
Thu, 29 Aug 2002 03:00:00 GMT

Bob Butle #4 / 8	M = Design(x,y,z) /vs/ Design x,y,z Quote: > I have been creating a lot of functions for which I don't require a > return value. Then I thought it would probably be much faster to define > these procedures as a sub instead of a function. > But the syntax looks kind'of strange: > Design x,y,z > as opposed to > M = Design(x,y,z) > Do many people use subs? I imagine it should be faster. Is it poor > programming style? If you don't like the looks of that syntax, use the alternate: Call Design(x,y,z) I almost always use Call for my own subs since it clearly identifies procedures as opposed to built-in commands. -- Please reply via the newsgroup only Sent via Deja.com http://www.deja.com/ Before you buy.
Thu, 29 Aug 2002 03:00:00 GMT

Morris W. Rothfeldt, Jr #5 / 8	M = Design(x,y,z) /vs/ Design x,y,z Thank you! Ugly or not, I like using call for the same reason. I know of no known performance hits and it clearly indicates that the processing is going to be done elsewhere. M. W. Rothfeldt Quote: > > I have been creating a lot of functions for which I don't require a > > return value. Then I thought it would probably be much faster to > define > > these procedures as a sub instead of a function. > > But the syntax looks kind'of strange: > > Design x,y,z > > as opposed to > > M = Design(x,y,z) > > Do many people use subs? I imagine it should be faster. Is it poor > > programming style? > If you don't like the looks of that syntax, use the alternate: > Call Design(x,y,z) > I almost always use Call for my own subs since it clearly identifies > procedures as opposed to built-in commands. > -- > Please reply via the newsgroup only > Sent via Deja.com http://www.deja.com/ > Before you buy.
Fri, 30 Aug 2002 03:00:00 GMT

Peter F. Dubuqu #6 / 8	M = Design(x,y,z) /vs/ Design x,y,z Quote: > Thank you! > Ugly or not, I like using call for the same reason. I know of no known > performance hits and it clearly indicates that the processing is going to be > done elsewhere. > M. W. Rothfeldt >> > I have been creating a lot of functions for which I don't require a >> > return value. Then I thought it would probably be much faster to >> define >> > these procedures as a sub instead of a function. >> > But the syntax looks kind'of strange: >> > Design x,y,z >> > as opposed to >> > M = Design(x,y,z) >> > Do many people use subs? I imagine it should be faster. Is it poor >> > programming style? >> If you don't like the looks of that syntax, use the alternate: >> Call Design(x,y,z) >> I almost always use Call for my own subs since it clearly identifies >> procedures as opposed to built-in commands. You mean you don't know all the built-in subs yourself? Me, I write 'em all the same way. It shouldn't matter whether a function I'm calling is one I've written or one that's built in. If I really need to know, I hit Shift+F2. If I get source code, it's mine; if I get the object browser, it's not. How do you distinguish between your own functions and built-in ones? --
Fri, 30 Aug 2002 03:00:00 GMT

alexradu.. #7 / 8	M = Design(x,y,z) /vs/ Design x,y,z --------------------------------------- Well, noy quite. Try this: Private Sub DoIt(intA As Integer) intA = 3 End Sub called by this: Private Sub Command1_Click() Dim intA As Integer DoIt intA MsgBox intA End Sub What do you expect as result ? 3, right ? Yes, the result is 3 because in this case intA is passed byref. Now this: Private Sub Command1_Click() Dim intA As Integer DoIt (intA) MsgBox intA End Sub It's perfectly legal, and the result should be 3. But the result is 0, because when you include the parantheses, VB assumes byVal. Finally: Private Sub Command1_Click() Dim intA As Integer Call DoIt(intA) MsgBox intA End Sub The "call" keyword will make VB use ByRef again, so the result is again 3. Conclusion: be careful with the calling of your subs/functions when you need to receive values as parameters. Alex. --------------------------------------- Sent via Deja.com http://www.deja.com/ Before you buy.
Fri, 30 Aug 2002 03:00:00 GMT

Bob Butle #8 / 8	M = Design(x,y,z) /vs/ Design x,y,z <cut> Quote: > >> If you don't like the looks of that syntax, use the alternate: > >> Call Design(x,y,z) > >> I almost always use Call for my own subs since it clearly identifies > >> procedures as opposed to built-in commands. > You mean you don't know all the built-in subs yourself? > Me, I write 'em all the same way. It shouldn't matter whether a function > I'm calling is one I've written or one that's built in. If I really need > to know, I hit Shift+F2. If I get source code, it's mine; if I get the > object browser, it's not. > How do you distinguish between your own functions and built-in ones? Actually, I do recognize my own as opposed to built-in almost always (unless it's code I haven't looked at for a while). In general I find it easier when doing maintenance programming, especially on somebody else's code, to have the Call keyword there. I try to write my code in such a way as to make it easier for whoever looks at it after me and that includes using Call. -- Please reply via the newsgroup only Sent via Deja.com http://www.deja.com/ Before you buy.
Sat, 31 Aug 2002 03:00:00 GMT

Page 1 of 1

[ 8 post ]