Simplifying Application Maintenance with Visual Basic 2005

Brad McCabe
Microsoft Corporation

June 2005

Summary: Learn to use some of the new features of Visual Basic 2005 such as compiler warnings and refactoring support to simplify the process of maintaining your existing applications. (7 printed pages)

Contents

Introduction
Compile-Time Warnings
Refactoring Scenarios
Conclusion

Introduction

With the release of Visual Studio 2005 developers will have the most productive environment to build applications that has been released to date. With new features like AutoCorrect, Edit & Continue, or IntelliSense in the Zone developers will be able to create applications faster than the could using prior versions. However, Visual Studio 2005 and Visual Basic 2005 provide lots of new features that help maintain existing applications that are migrated.

Compile-Time Warnings

On of the areas that Visual Basic 2005 helps developers is with enhanced support for compile-time warnings. Warnings differ from errors in the fact that an application can be compiled and work perfectly fine with warnings, but it is strongly suggested that you examine and make a choice as to whether to change your code as a result of these warnings.

Some of the new warnings are simple and straightforward. If you declare a variable but never use it in your code you with get a warning from the Visual Basic compiler to let you know of this unused variable. In most cases you can just delete the variable and clean up your code.

Figure 1. Warnings are shown in the IDE as a green underline with tool tips similar to an error.

Another common scenario is that you declare an object and attempt to use it before setting the object to something. You will normally catch something like this before deploying your application, but sometimes the problem occurs when the code executes down a rare branch in your code. Sometimes these are the toughest errors to debug because the problem seems to occur "randomly" from time to time.

Figure 2. Warnings can tell you when one particular branch of your code might have an error.

Another common source of runtime bugs is when you have a complex function that can have multiple points to exit from. If a developer exits a function before returning a value, it can cause unexpected results later in the application. In large, complex functions, it is easy to miss an exit or code path that does not return a value. This can often get missed in testing if the error lies on an obscure path that is not tested.

Figure 3. Warnings can highlight an exit from a complex function that does not properly return a value.

Loading existing applications into Visual Studio 2005 displays potential bugs as warnings that you may not have known about, and it allows you to fix your code before your users experience problems. In fact, many of these warnings apply to code written in Visual Studio 2002 or 2003. Even if you are not ready to migrate to Visual Studio 2005, you can open a copy of your solution in Visual Studio 2005 to view any warnings and make these changes manually to your existing solution. This provides you with a great way to improve your code even before you are ready to step up to 2005.

Over time code becomes difficult to read and maintain. One of the most common functions in code maintenance is to modify existing code to clean it up, make it more readable, or to prepare it for new features or functionality, while not changing the workings of the application. This is called refactoring.

Refactoring Scenarios

Let's look at a very basic scenario to start with. You have developed an application and named a common function OpenDatabaseConnection. This function is used throughout the application by numerous developers. Now you have been tasked with doing work on the system and you need to open a connection to a new database. You can name your new function more accurately as, say, OpenDocumentsConnection, to clearly tell others that your function will open a connection to the documents database. But what about reading the existing code? How will other developers in the future know what database OpenDatabaseConnection can access? They could easily call the older OpenDatabaseConnection function when they should be calling yours.

Often times this type of understanding becomes "tribal knowledge" in an organization and gets handed down from one developer to the next. The sharing of this knowledge normally starts when a new developer incorrectly uses the poorly named variable or function.

Visual Basic 2005 has a free add-in called Refactor! that allows you to safely make changes like this in a few mouse clicks.

Figure 4. With Refactor! you can safely and easily rework your code.

By right-clicking on the function name, I get a Refactor option on my context menu. (I can also click on the Smart Tag by the function name or use the keyboard shortcut (CTRL + ~) to access Refactor.) By selecting Symbolic Rename, I can choose to update the name of the older, existing function to something more meaningful, such as OpenMainConnection. Refactor will update every call in my solution to this function with the new name. Within a few seconds I have been able to clearly name the existing function and my new function to make the code more readable for future developers.

Refactor is much smarter then a simple global search-and-replace. Refactor understands the difference between other objects that might share the same name but be in a different scoop then the object you are renaming.

Another common scenario when maintaining existing code is that you want to reorder parameters to a function or procedure. This is much safer to do when your parameters are of different data types, as this will often raise an error in any sections of code that call your function that you forget to update. But what if you want to reorder two strings? How do you know everywhere that the method is called?

To do this with Visual Basic 2005 and Refactor, you can simply select the reorder parameter options and move the parameters around.

Figure 5. You can use the arrow keys to easily move parameters around.

After you are done, Refactor will show you each of the calls to the function you just updated and the proposed changes to update your code to the new syntax.

Figure 6. Refactor will show you all of the calls to the function and the changes that need to be made.

One of the most common scenarios with refactoring involves extracting a section of code into a separate method. Often, over time, a section of code starts out as a simple line or two and inserted into side of a large method. This is fine as long as that functionality does not need to be reused elsewhere in the application, or if the logic does not grow to include large amounts of additional code.

A very simple example of this is computing the volume of a cylinder. I first compute the area of the circle and then multiply by the height. Your code might look similar to that shown in Figure 7.

The problem is that if, later in your application, you want to compute just the area of the circle, you would need to duplicate this code. While the formula for the area of a circle is not going to change, if this was business logic in your application, it is very possible it will be modified over time. Duplicating it leaves open the possibility that one version will be updated but not the other.

Figure 7. Highlighting code and choosing the Extract method

With Refactor you can highlight the code and choose the Extract Method. Refactor will not only extract the method to the location you tell it, but it will create parameters for any needed variables and update the original location to correctly call the new method.

Figure 8. Extracting and updating code automatically

As you see in Figure 8, all of the code as been extracted and updated automatically with a few mouse clicks. We are now able to easily reuse the GetAreaOfCircle function in your form, or by marking it 'public' or extracting to it a central library we are able to use it anywhere in our application.

Refactor is able to automatically extract methods by simply cutting and pasting the code outside of an existing function, and it is smart enough to automatically wrap up the code as a function for you.

In total, the free version of Refactor ships with 16 refactoring options to help you clean up and improve your code with very little effort.

Conclusion

Besides the new productivity features and other enhancements to Visual Basic and Visual Studio 2005, the use of the new compiler warnings and tools such as Refactor help you reduce the amount of time and effort spent maintaining your existing code. Plus it allows you to focus on adding new functionality or modifying existing business logic to meet your changing needs.

For more information or to download Refactor, visit the Refactor! page on the Microsoft Visual Basic Developer Center.

© Microsoft Corporation. All rights reserved.