|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Function Vs. Sub ProcedureMaybe this is just some bad habits picked up...
But why not write everything in VB as a Function ? -If required later on you can always pass back a value. -You can pass in variables as required We always wrote everything in functions and tried to stay clear of procedures. Why make a Sub Bla() End Sub when you can make a Function? Miro if you know your method wont need to return something, why make it a function?
-- -iwdu15 What we did was this:
If a function should never have to return anything always return True Cuase that way...the next guy down the road 2 months later or a year later, if by chance something is requiered to be returned, then it can. Also, a Function can be called from anywhere. A Sub cannot. Gives you more freedom. (Im new to VB - teaching myself - so please tell me if this is not the case in VB.net) -One might say...make it a sub and convert it to a function when required. -The answer is...why make someone convert it when it can already be done. Miro Show quoteHide quote "iwdu15" <jmmgoalsteratyahoodotcom> wrote in message news:EC45D866-C232-41DE-83DD-5E4F09D5B10B@microsoft.com... > if you know your method wont need to return something, why make it a > function? > -- > -iwdu15 Why not write all of your apps as a single executable? That way you can
always reach any of the code. Why not write all of your tables in your server as a integer field and a text field and store XML in the text field? That way, you can change the storage without having to change the schema. In one of your examples, you mention creating a signature with a bool and returning a true. You have now typed the signature as a Boolean. That means if you really need an integer, you are changing the signature anyway, so your advantage of creating a function over a sub is no advantage. Perhaps then you go to a string instead. So, you pass back "true". You now can change it to a real string, or turn your integer (internal) into a "1", etc. Sounds promising, but you are boxing and unboxing both in your internal code and on the other side, where the consumer has to convert the generic string to a real type. Not wise. Now, you could retype to the proper type, but then you have no advantage over creating a sub and changing it to a function later. If you want to follow "proper .NET standards" (take this with a grain of salt, as I am not certain there are firm rules until you examine a particular problem explicitly), you throw exceptions for exceptional conditions, not obfuscate the condition with a false. You also have a good idea, up front, when you are going to return values. This is not always true, but a bit of homework up front can help you avoid massive signature changes. The other thing to consider is refactoring is a natural part of software development, even if penny pinchers are convinced that things get coded once and life goes on. If time is not entered in to refactor, you are going to create buggier software. End of story. -- Show quoteHide quoteGregory A. Beamer ************************************************* Think Outside the Box! ************************************************* "Miro" <miron***@golden.net> wrote in message news:uEAS3OojGHA.5036@TK2MSFTNGP04.phx.gbl... > Maybe this is just some bad habits picked up... > > But why not write everything in VB as a Function ? > -If required later on you can always pass back a value. > -You can pass in variables as required > > > We always wrote everything in functions and tried to stay clear of > procedures. > > Why make a Sub Bla() End Sub > when you can make a Function? > > Miro > > True,
I probably havnt gotten deep into VB to fully understand how it all fits in together later on. Hardest problem im finding in learning VB is trying to code in my old code and trying to convert it into vb and get it working. Thanks Miro Show quoteHide quote "Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@comcast.netNoSpamM> wrote in message news:OKJ9UXpjGHA.1204@TK2MSFTNGP02.phx.gbl... > Why not write all of your apps as a single executable? That way you can > always reach any of the code. > > Why not write all of your tables in your server as a integer field and a > text field and store XML in the text field? That way, you can change the > storage without having to change the schema. > > In one of your examples, you mention creating a signature with a bool and > returning a true. You have now typed the signature as a Boolean. That > means if you really need an integer, you are changing the signature > anyway, so your advantage of creating a function over a sub is no > advantage. > > Perhaps then you go to a string instead. So, you pass back "true". You now > can change it to a real string, or turn your integer (internal) into a > "1", etc. Sounds promising, but you are boxing and unboxing both in your > internal code and on the other side, where the consumer has to convert the > generic string to a real type. Not wise. Now, you could retype to the > proper type, but then you have no advantage over creating a sub and > changing it to a function later. > > If you want to follow "proper .NET standards" (take this with a grain of > salt, as I am not certain there are firm rules until you examine a > particular problem explicitly), you throw exceptions for exceptional > conditions, not obfuscate the condition with a false. You also have a good > idea, up front, when you are going to return values. This is not always > true, but a bit of homework up front can help you avoid massive signature > changes. > > The other thing to consider is refactoring is a natural part of software > development, even if penny pinchers are convinced that things get coded > once and life goes on. If time is not entered in to refactor, you are > going to create buggier software. End of story. > > -- > Gregory A. Beamer > > ************************************************* > Think Outside the Box! > ************************************************* > "Miro" <miron***@golden.net> wrote in message > news:uEAS3OojGHA.5036@TK2MSFTNGP04.phx.gbl... >> Maybe this is just some bad habits picked up... >> >> But why not write everything in VB as a Function ? >> -If required later on you can always pass back a value. >> -You can pass in variables as required >> >> >> We always wrote everything in functions and tried to stay clear of >> procedures. >> >> Why make a Sub Bla() End Sub >> when you can make a Function? >> >> Miro >> >> > > Don't. When you attempt to learn a new language and make it fit into
another language's pardigms and idioms, you will always get into trouble. Maybe not immediately, but eventually, doing this will come back to bite you. As for your original question - code subs whenever you don't expect a return value. Code functions when you do expect a return value. Also, put the following two lines at the beginning of every vb file: Option Explicit On Option Strict On Or better yet, use the IDE configuration to enforce these two options. Now the compiler will force you to declare all variables (Option Explicit On) and enforce type checking (Option Strict On). You'll catch a lot of errors before you even compile. Mike Ober. Show quoteHide quote "Miro" <miron***@golden.net> wrote in message news:u$Hm%23opjGHA.5020@TK2MSFTNGP02.phx.gbl... > True, > > I probably havnt gotten deep into VB to fully understand how it all fits in > together later on. > > Hardest problem im finding in learning VB is trying to code in my old code > and trying to convert it into vb and get it working. > > Thanks > > Miro > > > "Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@comcast.netNoSpamM> wrote in > message news:OKJ9UXpjGHA.1204@TK2MSFTNGP02.phx.gbl... > > Why not write all of your apps as a single executable? That way you can > > always reach any of the code. > > > > Why not write all of your tables in your server as a integer field and a > > text field and store XML in the text field? That way, you can change the > > storage without having to change the schema. > > > > In one of your examples, you mention creating a signature with a bool and > > returning a true. You have now typed the signature as a Boolean. That > > means if you really need an integer, you are changing the signature > > anyway, so your advantage of creating a function over a sub is no > > advantage. > > > > Perhaps then you go to a string instead. So, you pass back "true". You now > > can change it to a real string, or turn your integer (internal) into a > > "1", etc. Sounds promising, but you are boxing and unboxing both in your > > internal code and on the other side, where the consumer has to convert the > > generic string to a real type. Not wise. Now, you could retype to the > > proper type, but then you have no advantage over creating a sub and > > changing it to a function later. > > > > If you want to follow "proper .NET standards" (take this with a grain of > > salt, as I am not certain there are firm rules until you examine a > > particular problem explicitly), you throw exceptions for exceptional > > conditions, not obfuscate the condition with a false. You also have a good > > idea, up front, when you are going to return values. This is not always > > true, but a bit of homework up front can help you avoid massive signature > > changes. > > > > The other thing to consider is refactoring is a natural part of software > > development, even if penny pinchers are convinced that things get coded > > once and life goes on. If time is not entered in to refactor, you are > > going to create buggier software. End of story. > > > > -- > > Gregory A. Beamer > > > > ************************************************* > > Think Outside the Box! > > ************************************************* > > "Miro" <miron***@golden.net> wrote in message > > news:uEAS3OojGHA.5036@TK2MSFTNGP04.phx.gbl... > >> Maybe this is just some bad habits picked up... > >> > >> But why not write everything in VB as a Function ? > >> -If required later on you can always pass back a value. > >> -You can pass in variables as required > >> > >> > >> We always wrote everything in functions and tried to stay clear of > >> procedures. > >> > >> Why make a Sub Bla() End Sub > >> when you can make a Function? > >> > >> Miro > >> > >> > > > > > > > I have the Explicit and Strict both on.
Just slowly creating an exe app and learning as I go. ( when I have time ) :) Those were both a pain in the butt in the beginning but I do like them - a lot. Thanks for your help, Miro Show quoteHide quote "Michael D. Ober" <ober***@.alum.mit.edu.nospam> wrote in message news:JWqjg.5088$lf4.2039@newsread1.news.pas.earthlink.net... > Don't. When you attempt to learn a new language and make it fit into > another language's pardigms and idioms, you will always get into trouble. > Maybe not immediately, but eventually, doing this will come back to bite > you. > > As for your original question - code subs whenever you don't expect a > return > value. Code functions when you do expect a return value. Also, put the > following two lines at the beginning of every vb file: > > Option Explicit On > Option Strict On > > Or better yet, use the IDE configuration to enforce these two options. > Now > the compiler will force you to declare all variables (Option Explicit On) > and enforce type checking (Option Strict On). You'll catch a lot of > errors > before you even compile. > > Mike Ober. > > "Miro" <miron***@golden.net> wrote in message > news:u$Hm%23opjGHA.5020@TK2MSFTNGP02.phx.gbl... >> True, >> >> I probably havnt gotten deep into VB to fully understand how it all fits > in >> together later on. >> >> Hardest problem im finding in learning VB is trying to code in my old >> code >> and trying to convert it into vb and get it working. >> >> Thanks >> >> Miro >> >> >> "Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@comcast.netNoSpamM> wrote in >> message news:OKJ9UXpjGHA.1204@TK2MSFTNGP02.phx.gbl... >> > Why not write all of your apps as a single executable? That way you can >> > always reach any of the code. >> > >> > Why not write all of your tables in your server as a integer field and >> > a >> > text field and store XML in the text field? That way, you can change >> > the >> > storage without having to change the schema. >> > >> > In one of your examples, you mention creating a signature with a bool > and >> > returning a true. You have now typed the signature as a Boolean. That >> > means if you really need an integer, you are changing the signature >> > anyway, so your advantage of creating a function over a sub is no >> > advantage. >> > >> > Perhaps then you go to a string instead. So, you pass back "true". You > now >> > can change it to a real string, or turn your integer (internal) into a >> > "1", etc. Sounds promising, but you are boxing and unboxing both in >> > your >> > internal code and on the other side, where the consumer has to convert > the >> > generic string to a real type. Not wise. Now, you could retype to the >> > proper type, but then you have no advantage over creating a sub and >> > changing it to a function later. >> > >> > If you want to follow "proper .NET standards" (take this with a grain >> > of >> > salt, as I am not certain there are firm rules until you examine a >> > particular problem explicitly), you throw exceptions for exceptional >> > conditions, not obfuscate the condition with a false. You also have a > good >> > idea, up front, when you are going to return values. This is not always >> > true, but a bit of homework up front can help you avoid massive > signature >> > changes. >> > >> > The other thing to consider is refactoring is a natural part of >> > software >> > development, even if penny pinchers are convinced that things get coded >> > once and life goes on. If time is not entered in to refactor, you are >> > going to create buggier software. End of story. >> > >> > -- >> > Gregory A. Beamer >> > >> > ************************************************* >> > Think Outside the Box! >> > ************************************************* >> > "Miro" <miron***@golden.net> wrote in message >> > news:uEAS3OojGHA.5036@TK2MSFTNGP04.phx.gbl... >> >> Maybe this is just some bad habits picked up... >> >> >> >> But why not write everything in VB as a Function ? >> >> -If required later on you can always pass back a value. >> >> -You can pass in variables as required >> >> >> >> >> >> We always wrote everything in functions and tried to stay clear of >> >> procedures. >> >> >> >> Why make a Sub Bla() End Sub >> >> when you can make a Function? >> >> >> >> Miro >> >> >> >> >> > >> > >> >> >> > > > Hello Miro,
Write code that mirrors your intent so that in 6 months when you , or more likely someone else, has to maintain the code they dont have to figure out if this chunk of code is supposed to be returning a value. We don't write code for computers, we write code for people. Your code should be well organized and easy to read. If we wrote code for computers we'd all be writing in hex. Hell with that noise. Also, a function has slightly more overhead than a sub. Even if you do not return a value, the compiler sets up a return value anyways. -Boo Show quoteHide quote > Maybe this is just some bad habits picked up... > > But why not write everything in VB as a Function ? > -If required later on you can always pass back a value. > -You can pass in variables as required > We always wrote everything in functions and tried to stay clear of > procedures. > > Why make a Sub Bla() End Sub > when you can make a Function? > Miro > GhostInAK,
I should have written that too. I did not know what you wrote when I was writing my message but I for 100% agree in what you wrote. (To show another ones opinion) :-) CorShow quoteHide quote "GhostInAK" <ghosti***@gmail.com> schreef in bericht news:c71747b4177dc8c85c8184528cb6@news.microsoft.com... > Hello Miro, > > Write code that mirrors your intent so that in 6 months when you , or more > likely someone else, has to maintain the code they dont have to figure out > if this chunk of code is supposed to be returning a value. We don't write > code for computers, we write code for people. Your code should be well > organized and easy to read. If we wrote code for computers we'd all be > writing in hex. Hell with that noise. > > Also, a function has slightly more overhead than a sub. Even if you do > not return a value, the compiler sets up a return value anyways. > > -Boo > >> Maybe this is just some bad habits picked up... >> >> But why not write everything in VB as a Function ? >> -If required later on you can always pass back a value. >> -You can pass in variables as required >> We always wrote everything in functions and tried to stay clear of >> procedures. >> >> Why make a Sub Bla() End Sub >> when you can make a Function? >> Miro >> > > Miro,
Just because there would be a breaking change (the programs are less easy upwards compatible) doing what you suggest. My idea would be to insert extra to use instead of those the word "Method", a method withouth a return would be than the same as a Sub and with a return a function. However to be honest, I don't believe this add much and makes it again more difficult to descibe why that is done. In C derivied languages (C C++ Java JavaScript C# etc) is used the word Void to declare that something is what is a Sub in VBNet, I find this as well very artificial. Just my thought, Cor Show quoteHide quote "Miro" <miron***@golden.net> schreef in bericht news:uEAS3OojGHA.5036@TK2MSFTNGP04.phx.gbl... > Maybe this is just some bad habits picked up... > > But why not write everything in VB as a Function ? > -If required later on you can always pass back a value. > -You can pass in variables as required > > > We always wrote everything in functions and tried to stay clear of > procedures. > > Why make a Sub Bla() End Sub > when you can make a Function? > > Miro > > A function can be seen as a subroutine that also returns a value. In
that regard, a function can do more than a subroutine, but that doesn't mean that a function always is better than a subroutine. If you look at variables the same way, that would mean that an array is always better than a regular variable, as it can hold more values. The conclusion would be that you should always use arrays instead of regular variables. That is obviously not true. You should use the structure that best resembles what the code is supposed to do. Mystical unused return values only makes the code confusing. If the code later changes so that the subroutine has to be changed to a function, then that's fine. That changes the signature of the class, but that is as it should be. If the method needs to return a value, the code that uses it should also be revised to handle that value. Miro wrote: Show quoteHide quote > Maybe this is just some bad habits picked up... > > But why not write everything in VB as a Function ? > -If required later on you can always pass back a value. > -You can pass in variables as required > > > We always wrote everything in functions and tried to stay clear of > procedures. > > Why make a Sub Bla() End Sub > when you can make a Function? > > Miro > Goran,
I don't believe, because of the sense of your message, that you means this part as it is readable. > You should use the structure that best resembles what the code is supposed Readable as:> to do. You should use the structure instead of a class.................................. Just before somebody would misunderstand you. :-) CorHello Cor Ligthert [MVP],
I do believe Goran was meaning structure in the sense of application design, or paradigm. A way of doing something. I don't think they were intending the word structure to mean a data storage mechanism. -Boo Show quoteHide quote > Goran, > > I don't believe, because of the sense of your message, that you means > this part as it is readable. > >> You should use the structure that best resembles what the code is >> supposed to do. >> > Readable as: > You should use the structure instead of a > class.................................. > Just before somebody would misunderstand you. > > :-) > > Cor > Boo,
> I do believe Goran was meaning structure in the sense of application Me to, my message was to prevent that somebody would read it wrong by just > design, or paradigm. A way of doing something. I don't think they were > intending the word structure to mean a data storage mechanism. > searching and taking one sentence. Cor Show quoteHide quote "GhostInAK" <ghosti***@gmail.com> schreef in bericht news:c71747b4179578c85d3ddbd2ceee@news.microsoft.com... > Hello Cor Ligthert [MVP], > > I do believe Goran was meaning structure in the sense of application > design, or paradigm. A way of doing something. I don't think they were > intending the word structure to mean a data storage mechanism. > > -Boo > >> Goran, >> >> I don't believe, because of the sense of your message, that you means >> this part as it is readable. >> >>> You should use the structure that best resembles what the code is >>> supposed to do. >>> >> Readable as: >> You should use the structure instead of a >> class.................................. >> Just before somebody would misunderstand you. >> >> :-) >> >> Cor >> > > 
Other interesting topics
Marshal Structure containing arrays to function in DLL
OOP object instance assignment in sub new() Scanning Option Group (VB 6 Option Button Control Array) Auto-Updates using MSI ExitWindowsEx function not working. String, not Boolean VB.NET: RasDial + CallBacks + throwing events = frozen UI? Is there a Function and Function Argument generic self-reference? Linking childform to Main Form in VB6 Passing an array of to a Sub |
|||||||||||||||||||||||
