Practical Standards for Microsoft Visual Basic .NET (Pro-Developer)

[Previous] [Next]

Chapter 11

Rarely is a process within code accomplished with a single procedure that executes from the top down. Most processes are accomplished with multiple procedures, sometimes including more than one module. If you follow the execution path of a particular process, you'll usually experience many twists and turns, often spurred by decisions based on the evaluation of an expression. Initiating the given process a second time might cause an entirely different path of execution if even a single condition within the program has changed, such as the user entering new text in a text box. Frequently, the multiple paths of execution cause code to take on a rather labyrinthine appearance. Obviously, the ability to easily discern the changes in the execution path is important for being able to read the code and debug it.

As I've said, the decisions that create the twists and turns of an executing process are often made based on the evaluation of an expression or multiple expressions. Thus, it's important to make the decision points in the flow of code as understandable as possible. This involves knowing what branching structure to use in a situation, as well as when to use it. For instance, you need to know when using Select Case is more appropriate than using If Then Else . Using the proper construct in the proper place will make your code easier to read and make it easier to include additional expressions at a later time.

Regardless of the decision construct you implement in a given situation, you'll have to evaluate an expression. Most expressions can be written in many different ways; nevertheless, there's generally only one preferred way to write any given expression. Writing expressions correctly is critical, and I'll provide many Practical Applications in this chapter to help you create proper expressions. At best, poorly written expressions are difficult to read and understand. At worst, such expressions might cause the program to fail.

NOTE


All decision constructs must follow strict indentation rules. See Chapter 8, "Formatting Code," for specific information on proper indentation.

Goals of Controlling Code Flow


Your goals when controlling code flow should include

Категории