Function Vs. Sub Procedure

  • Thread starter Thread starter Miro
  • Start date Start date
M

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
 
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
 
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!
*************************************************
 
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
 
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.
 
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
 
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
 
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
 
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
 
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.
 
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
 
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
 
Boo,
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.

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

Cor
 
Back
Top