Function Vs. Sub Procedure

[Miro]

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

[iwdu15]

RE: Function Vs. Sub Procedure

if you know your method wont need to return something, why make it a function?
--
-iwdu15

[Miro]

Re: Function Vs. Sub Procedure

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


"iwdu15" <jmmgoalsteraty ahoodotcom> wrote in message
news:EC45D866-C232-41DE-83DD-5E4F09D5B10B@mi crosoft.com...[color=blue]
> if you know your method wont need to return something, why make it a
> function?
> --
> -iwdu15[/color]

[Cowboy \(Gregory A. Beamer\)]

Re: Function Vs. Sub Procedure

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" <mironagy@golde n.net> wrote in message
news:uEAS3OojGH A.5036@TK2MSFTN GP04.phx.gbl...[color=blue]
> 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
>
>[/color]

[Miro]

Re: Function Vs. Sub Procedure

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.netNoS pamM> wrote in
message news:OKJ9UXpjGH A.1204@TK2MSFTN GP02.phx.gbl...[color=blue]
> 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" <mironagy@golde n.net> wrote in message
> news:uEAS3OojGH A.5036@TK2MSFTN GP04.phx.gbl...[color=green]
>> 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
>>
>>[/color]
>
>[/color]

[Michael D. Ober]

Re: Function Vs. Sub Procedure

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" <mironagy@golde n.net> wrote in message
news:u$Hm%23opj GHA.5020@TK2MSF TNGP02.phx.gbl. ..[color=blue]
> True,
>
> I probably havnt gotten deep into VB to fully understand how it all fits[/color]
in[color=blue]
> 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.netNoS pamM> wrote in
> message news:OKJ9UXpjGH A.1204@TK2MSFTN GP02.phx.gbl...[color=green]
> > 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[/color][/color]
and[color=blue][color=green]
> > 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[/color][/color]
now[color=blue][color=green]
> > 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[/color][/color]
the[color=blue][color=green]
> > 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[/color][/color]
good[color=blue][color=green]
> > 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[/color][/color]
signature[color=blue][color=green]
> > 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" <mironagy@golde n.net> wrote in message
> > news:uEAS3OojGH A.5036@TK2MSFTN GP04.phx.gbl...[color=darkred]
> >> 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
> >>
> >>[/color]
> >
> >[/color]
>
>
>[/color]

[Miro]

Re: Function Vs. Sub Procedure

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



"Michael D. Ober" <obermd.@.alum. mit.edu.nospam> wrote in message
news:JWqjg.5088 $lf4.2039@newsr ead1.news.pas.e arthlink.net...[color=blue]
> 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" <mironagy@golde n.net> wrote in message
> news:u$Hm%23opj GHA.5020@TK2MSF TNGP02.phx.gbl. ..[color=green]
>> True,
>>
>> I probably havnt gotten deep into VB to fully understand how it all fits[/color]
> in[color=green]
>> 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.netNoS pamM> wrote in
>> message news:OKJ9UXpjGH A.1204@TK2MSFTN GP02.phx.gbl...[color=darkred]
>> > 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[/color][/color]
> and[color=green][color=darkred]
>> > 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[/color][/color]
> now[color=green][color=darkred]
>> > 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[/color][/color]
> the[color=green][color=darkred]
>> > 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[/color][/color]
> good[color=green][color=darkred]
>> > 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[/color][/color]
> signature[color=green][color=darkred]
>> > 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" <mironagy@golde n.net> wrote in message
>> > news:uEAS3OojGH A.5036@TK2MSFTN GP04.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
>> >>
>> >>
>> >
>> >[/color]
>>
>>
>>[/color]
>
>
>[/color]

[GhostInAK]

Re: Function Vs. Sub Procedure

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
[color=blue]
> 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
>[/color]

[Cor Ligthert [MVP]]

Re: Function Vs. Sub Procedure

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

"Miro" <mironagy@golde n.net> schreef in bericht
news:uEAS3OojGH A.5036@TK2MSFTN GP04.phx.gbl...[color=blue]
> 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
>
>[/color]

[Cor Ligthert [MVP]]

Re: Function Vs. Sub Procedure

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)

:-)

Cor

"GhostInAK" <ghostinak@gmai l.com> schreef in bericht
news:c71747b417 7dc8c85c8184528 cb6@news.micros oft.com...[color=blue]
> 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
>[color=green]
>> 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
>>[/color]
>
>[/color]

[Göran Andersson]

Re: Function Vs. Sub Procedure

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:[color=blue]
> 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
>[/color]

[Cor Ligthert [MVP]]

Re: Function Vs. Sub Procedure

Goran,

I don't believe, because of the sense of your message, that you means this
part as it is readable.
[color=blue]
> You should use the structure that best resembles what the code is supposed
> to do.[/color]

Readable as:
You should use the structure instead of a
class.......... ............... .........

Just before somebody would misunderstand you.

:-)

Cor

[GhostInAK]

Re: Function Vs. Sub Procedure

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
[color=blue]
> Goran,
>
> I don't believe, because of the sense of your message, that you means
> this part as it is readable.
>[color=green]
>> You should use the structure that best resembles what the code is
>> supposed to do.
>>[/color]
> Readable as:
> You should use the structure instead of a
> class.......... ............... .........
> Just before somebody would misunderstand you.
>
> :-)
>
> Cor
>[/color]

[Cor Ligthert [MVP]]

Re: Function Vs. Sub Procedure

Boo,
[color=blue]
> 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.
>[/color]

Me to, my message was to prevent that somebody would read it wrong by just
searching and taking one sentence.

Cor

"GhostInAK" <ghostinak@gmai l.com> schreef in bericht
news:c71747b417 9578c85d3ddbd2c eee@news.micros oft.com...[color=blue]
> 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
>[color=green]
>> Goran,
>>
>> I don't believe, because of the sense of your message, that you means
>> this part as it is readable.
>>[color=darkred]
>>> You should use the structure that best resembles what the code is
>>> supposed to do.
>>>[/color]
>> Readable as:
>> You should use the structure instead of a
>> class.......... ............... .........
>> Just before somebody would misunderstand you.
>>
>> :-)
>>
>> Cor
>>[/color]
>
>[/color]