Using Functions and Subroutines


Years ago I worked for a software company that sometimes published software developed outside of the organization, all for a non-Windows platform. While most of these programs were written in the C language, we also published software written in Pascal, assembly language, and good ol' BASIC. I inherited one such external application written entirely in BASIC, a program that assisted the user in 3-D modeling and graphic rendering. It was a complex program, containing about 30,000 lines of source code. The problem was that it was one large block of 30,000 source code lines. No comments, no variable names longer than a few characters, no extra-strength buffered aspirin product. Just thousands of lines of code with flow control statements jumping this way and that. And, of course, it had a bug.

I was able to move past that event in my life without too much therapy, but at the time it was a shock to see code in that condition. And it was so unnecessary, because that flavor of BASIC was a procedural language, just like C and Pascal. Procedural languages allow you to break your code into named blocks of logic, called procedures. These procedures allow the programmer to take a "divide and conquer" approach to programming; you write procedures that accomplish a specific logical portion of the code within your entire application, and then access these procedures from other procedures.

Visual Basic includes three types of procedures.

  • Subroutines. These procedures, also called "sub procedures," do a bunch of work and then return to the calling procedure. Data can be sent into the subroutine through its argument list, and some values may come back through that same list, but there is no official final result sent back from the procedure. A subroutine does its work, and once it is complete, the calling code continues on its merry way.

  • Functions. Functions are just like subroutines, with one additional feature. You can return a single value or object instance from the function as its official result. Usually, the calling code takes this return value into consideration when it completes its own logic.

  • Properties. When used, properties actually look like variables. You assign and retrieve values to and from properties just like you would for a variable. However, properties include hidden code, often used to validate the data being assigned to the property.

Subroutines, functions, and properties are the code members of each class or similar type. I'll delay discussion of properties until a little later in the chapter. For now, let's enjoy functions and subroutines, which together are also known as methods. Let's start with subroutines. To call a subroutine, type its name as a statement, followed by a set of parentheses. Any data you need to send to the subroutine goes in the parentheses. For instance, the following subroutine call does some work, passing the ID number of a customer and a starting date:

DoSomeWork(customerID, startDate) 


Each subroutine defines the data type and order of the arguments you pass. This argument list may include one or more optional arguments, which are assigned default values if you don't include them. A subroutine might also be overloaded, defining different possible argument lists based on the number and data type of the arguments. We'll encounter a lot of these later.

Functions are a little more interesting because they return a usable value. Often, this value is assigned to a variable.

Dim balanceDue As Boolean balanceDue = HasOutstandingBalance(customerID) 


Then you can do something with this result. If you want, you can ignore the return value of a function, and we already have. The MsgBox function used earlier returns the identity of the on-screen button clicked by the user. If you only include an OK button (the default), you probably don't care which button the user presses.

MsgBox("Go ahead, click the OK button.") 


But you can also capture the result of the button.

whichButton = MsgBox("Click Yes or No.", MsgBoxStyle.YesNo) 


In this case, whichButton will either be MsgBoxResult.Yes or MsgBoxResult.No, two of the possible results defined by the MsgBox function.




Start-to-Finish Visual Basic 2005. Learn Visual Basic 2005 as You Design and Develop a Complete Application
Start-to-Finish Visual Basic 2005: Learn Visual Basic 2005 as You Design and Develop a Complete Application
ISBN: 0321398009
EAN: 2147483647
Year: 2006
Pages: 247
Authors: Tim Patrick

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net