Subroutines
As your programs become larger and more complicated, it becomes harder and harder to follow what is
going on—meaning it will be harder to fix bugs. In addition, you may find sections of code being
repeated several times. The cure for both problems is to use procedures—separate sections of code
which perform specific tasks. In VB, procedures come in two flavors: subroutines and functions.
Technically speaking, the only difference between subroutines and functions is that a function returns a
value, while a subroutine does not. Philosophically, however, they should be treated differently (it’s
required in this course). Subroutines do things—move data around, prompt the user, display results.
Functions simply do the math (or string manipulation or whatever) needed to return the value; they
should not have any other side effects. (VB doesn’t require this; I do!)
Both subroutines and functions can take parameters (also called arguments). These are values passed to
the procedure for it to act upon.
Subroutines have two faces: The definition which contains the code that makes them work; and the call,
a line of code which uses the subroutine’s name to cause that code to execute. Here’s an example:
Public Class Form1
Private Sub DoSomeStuff()
Me.BackColor = Color.Blue
Me.Text = "I'm so blue!"
End Sub
Private Sub btnDoStuff_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles btnDoStuff.Click
DoSomeStuff()
End Sub
End Class
The four lines of code beginning with Private Sub DoSomeStuff() are the definition of the subroutine;
they give it it’s name (“DoSomeStuff”) and contain the code that executes when it is called. (Note: “Me”
refers to the form, Form1.)
The one line of code in btnDoStuff_Click (which is a Sub itself, by the way) is DoSomeStuff(). This is the
call to the routine. That’s all that’s needed to get the code to run; just type the name of the Sub. (The
parentheses are required, but VB will stick them on for you if you forget.)
We can add more flexibility to DoSomeStuff by giving it a parameter. Let’s give it a String variable as a
parameter, and this string will become the caption of the form:
Public Class Form1
Private Sub DoSomeStuff(ByVal Caption As String)
Me.BackColor = Color.Blue
Me.Text = Caption
End Sub
Private Sub btnDoStuff_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles btnDoStuff.Click
DoSomeStuff("I've got a parameter!")
End Sub
End Class
We have passed a literal string as a parameter, but we could have passed a variable, an expression, or
even the result of a function:
Public Class Form1
Private Sub DoSomeStuff(ByVal Caption As String)
Me.BackColor = Color.Blue
Me.Text = Caption
End Sub
Private Sub btnDoStuff_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles btnDoStuff.Click
DoSomeStuff(InputBox("Enter a caption for the form:"))
End Sub
End Class
Whatever is inside DoSomeStuff’s parentheses gets evaluated first, and is then passed to the subroutine.
When it gets there, it is contained in the variable “Caption”, which becomes a local variable in the Sub. It
is bad form (and not allowed in this class) to change the value of a parameter inside a procedure.
Create your own project and write a few Subs of your own. Experiment with parameters and passing
different types of values to the Subs.