SUMMARY 149

Summary

It’s been a long chapter, but we wouldn’t be able to go far without the information presented here. You have learned the base data types supported by Visual Basic, how to declare variables, and when to use them. Actually, the base data types aren’t supplied by Visual Basic; they’re part of the Common Language Runtime (CLR) and are the same for all languages. At this point, it doesn’t really make much difference what part of .NET supplies each feature (the CLR, the Framework, or Visual Basic itself).

You’ve also learned how to store sets of values to an array, which is a great convenience. Arrays have always been a prime tool for programmers, and they’ve gotten so much better in .NET. You will read more about arrays in Chapter 11.

The base types supported by CLR are just too basic for the needs of a real application. To store more complicated information (like customers, accounts and so on), you can create your own custom structures. After defining the structure of the information, you can declare variables with the same structure. These variables behave like objects (even though they’re not technically objects), because they expose the fields of the structure as properties.

The most interesting information presented in this chapter is the notion of variables as objects. That will all make much more sense in Chapter 8, where we’ll discuss classes formally and you’ll learn how to build your own classes and declared variables that represent them. Until then, think of variables as entities that expose some functionality through properties and methods. Properties and methods are just names following the name of a variable.

Chapter 4

Writing and Using Procedures

The one thing you should have learned about programming in Visual Basic so far is that an application is made up of small, self-contained segments. The code you write isn’t a monolithic listing; it’s made up of small segments called procedures, and you work on one procedure at a time.

For example, when you write code for a control’s Click event, you concentrate on the event at hand—namely, how the program should react to the Click event. What happens when the control is double-clicked, or when another control is clicked, is something you will worry about later, in another control’s event handler. This “divide and conquer” approach isn’t unique to programming events. It permeates the Visual Basic language, and even the longest applications are written by breaking them into small, well-defined tasks. Each task is performed by a separate procedure that is written and tested separately from the others.

Procedures are also used for implementing repeated tasks, such as frequently used calculations. Suppose you’re writing an application that, at some point, must convert temperatures between different scales or calculate the smaller of two numbers. You can always do the calculations inline and repeat them in your code wherever they are needed, or you can write a procedure that performs the calculations and call this procedure. The benefit of the second approach is that code is cleaner and easier to understand and maintain. If you discover a more efficient way to implement the same calculations, you need change the code in only one place. If the same code is repeated in several places throughout the application, you will have to change every instance.

The two types of procedures supported by Visual Basic are the topics we’ll explore in this chapter: subroutines and functions—the building blocks of your applications. We’ll discuss them in detail, how to call them with arguments and how to retrieve the results returned by the functions. You may find that some of the topics discussed in this chapter are rather advanced, but I wanted to exhaust the topic in a single chapter, rather than having to interrupt the discussion of other topics to explain an advanced, procedure-related technique. You can skip the sections you find difficult at first reading and come back to these sections later, or look up the technique as needed.