Take a look at any major integrated development environment (IDE) today and you are bound to discover “refactoring” options... more

Take a look at any major integrated development environment (IDE) today and you are bound to discover “refactoring” options somewhere at the tip of your fingers. And if you are following developments in the programming community, you have surely come across a number of articles and books on the subject. For some, it is the most important development in the way they code since the inception of design patterns.

Unlike some other trends, refactoring is being embraced and spread eagerly by programmers and coders themselves because it helps them do their work better and be more productive. Without a doubt, applying refactoring has become an important part of programmers’ day-to-day labor no matter the tools, programming language, or type of program being developed. Visual Basic is a part of this: at this moment, the same wave of interest for refactoring in the programming community in general is happening inside the Visual Basic community.

In this introduction,

• I start out by taking a look at what refactoring is and why it is important and then discuss a few of the benefits that refactoring delivers.

• I also address some of the most common misconceptions about refactoring.

• In the second part of this chapter I want you to take a look at the specifics of Visual Basic as a programming language and how refactoring can be even more relevant for Visual Basic programmers because of some historic issues related to Visual Basic.

I’ll start with some background on refactoring in general.

... less

Before I go into the details of refactoring procedures, the theory and mechanics behind it, it is a good idea to start with... more

Before I go into the details of refactoring procedures, the theory and mechanics behind it, it is a good idea to start with a very simple yet complete application in order to gain perspective on the process I am trying to describe. This way, as I start going into detail about specific refactoring or code smells, you’ll have a better sense of where each of these elements of the refactoring process fits and of the purpose behind it.

In this chapter you are going to see a simple application, consisting only of a single form and a single event-handling procedure, in its first reincarnation. Soon, requirements will start to grow. As the application strives to respond to new requirements, flaws and imperfections in the design will materialize. I will identify the code smells and eliminate them as I progress. I’ll follow the refactoring process as I perform these modifications. As you have already seen, the refactoring process consists of three steps:

1. Identifying the smell

2. Using specific refactoring to eliminate the smell

3. Executing tests to validate the changes

I’ll focus on the refactoring process, but I will explain and develop the complete application as I go along. Of course, since all I am trying to do in this chapter is give you the first taste of refactoring, the application will be moderate in size and detail.

... less

Many techniques and methodologies make you produce and maintain artifacts, in addition to source code, as an integral part... more

Many techniques and methodologies make you produce and maintain artifacts, in addition to source code, as an integral part of the project—things like documentation, diagrams, and so on. Some approaches are very strict in controlling the way you code, imposing rules and guidelines that confine the way you program in order to make your code more uniform. In all these cases, you may often feel that an additional burden has encumbered this already demanding line of work. It can easily make you reluctant to adopt new techniques. With refactoring the rules are not cast in stone, nor do have you to deal with any additional baggage. On the contrary, the more expert you become in refactoring techniques, the more confident you are with the code. What refactoring does is to make you feel you are in charge. The productivity gain and coding proficiency that come from refactoring are further enhanced by the right set of tools.

When I talk about assembling a refactoring toolkit, which is the topic of this chapter, I consider the following three pieces of software mandatory, no matter the size of your team or project, your methodology, or the type of software you are making:

• An automated refactoring tool

• A unit-testing framework

• A source-code version-control system

Only one is directly related to performing refactoring transformations, while the other two are in my opinion indispensable for any type of serious refactoring work. The refactoring tool can automate certain refactorings but only when it is used together with unit testing and source-code control will you have the freedom and security to perform refactoring continuously and on a large scale.

In this chapter I’ll discuss the first two items in detail. Since I haven’t met many teams that don’t use some kind of version-control system, I will not go into any great detail about it other than to dedicate just enough space to treat version-control issues relevant to refactoring.

As you will see, there is no single tool that encompasses all the functionality you need for a successful refactoring process. Visual Studio is on the road to providing a unified solution, but for the time being you have to make an effort to assemble this refactoring toolkit yourself.

Note

If you would like to learn about refactoring techniques right away, you can skip this chapter and come back to this discussion of tools later on, after you have read about each individual refactoring.

... less

Refactoring is a very practical, hands-on type of art. Therefore, it is difficult to talk about the mechanics, motivation... more

Refactoring is a very practical, hands-on type of art. Therefore, it is difficult to talk about the mechanics, motivation, and benefits of refactoring unless there is a good illustration to accompany it. While small snippets of code serve well to prove a specific point, you might be left wanting a look at the bigger picture, or an example of of refactoring in a real-life situation.

In order to remedy this problem, I have decided to present you with a real-world scenario. I will go on from here to implement the complete and fully functional application. I will apply refactoring as I go and explain the logic behind the refactoring process in detail. That way, not only will each refactoring technique be illustrated with code samples, but you will see the refactoring process applied throughout the lifetime of this sample application.

I will end each chapter in the book with a demonstration of refactoring in practice. I will use the Rent-a-Wheels application for this purpose. Throughout the book you will witness the progress of the application from a simple but fully functional GUI-based prototype to a full-blown tiered enterprise application.

Since I will refer to the Rent-a-Wheels application in almost every chapter that is to follow, you should try to analyze the application while reading this chapter and think of possible weaknesses in the design and implementation. This way, as you progress with the book you will be able to compare your initial judgment with weaknesses and smells I will expose and deal with later on.

My intention is to present you with a realistic scenario. I have even written down a few conversations with the client so you can put yourself in the same situation, that of analyzing and distilling raw information from typical laymen who might want to use your product. I also introduce another character in this chapter. Tim is our typical apprentice programmer, already in command of basic Visual Basic programming techniques, but not at all familiar with refactoring or some of the more complex design principles. He will eagerly get the job done, but, as you will see throughout the book, this is not sufficient for well-designed, refined, industrial-strength applications. In this chapter I will let Tim explain in his own words the work he has performed on the Rent-a-Wheels prototype implementation.

Note

I suggest you download the complete project from www.wrox.com and use the IDE to follow as we go along. I have included a lot of code listings in the text, but you’ll have an easier time finding your way around if you use Visual Studio with the complete source code at hand.

I’ll start presenting the application right from the inception. This way, you can see the business case for the application and observe work on the application in progress. Bear in mind that this chapter is not meant to teach you software design or analysis. While you are reading it, I hope this chapter does two things:

• I hope it helps you feel as if you’re having a typical day in the office and using some very familiar techniques and styles.

• Then, I hope to use this familiarity as an entry point to discuss some typical VB approaches to programming and how they relate to refactoring and software design in general.

... less

Almost all high-level programming languages implement the concept of types. By classifying values and expressions into types... more

Almost all high-level programming languages implement the concept of types. By classifying values and expressions into types, you achieve a number of benefits: safety, optimization, abstraction, and modularity.

Most modern programming languages can be placed into one of two categories: statically typed or dynamically typed.

• In statically typed languages, type resolution is performed at compile time, and type information is provided explicitly in the code by the programmer himself in the form of a variable declaration.

• In dynamically typed languages, data types are not declared, and type information is not available until execution.

Visual Basic can be statically or dynamically typed. This behavior of VB’s compiler is controlled by the Option Explicit statement.

Languages are also differentiated by the level of type safety they provide. Strongly typed languages disallow operations on arguments that have a wrong type. Other type languages permit these operations by implicitly casting the types of arguments so that the operations in question can be performed, guided by rules that take both operands into account. The disallowing or allowing of implicit conversions in VB code is controlled by VB’s Option Strict statement.

Note

In Visual Basic 2008 there is new and different type of Option statement. Option Infer lets you omit the As clause of your local variable declaration, but the code is still statically typed. In that sense it is more of a productivity feature than an additional type-system behavior. Since I deal with VB 2008 novelties in Chapter 15, I have left the discussion of Option Infer for that chapter.

Table 5-1 shows the kinds and levels of typing enforced in VB by the compiler when the Option Explicit and Option Strict options are active or inactive.

This versatility of VB is unique and enables the effective use of VB for variety of purposes, from fast prototyping to industrial-strength applications. While .NET as a platform is mostly statically oriented (other languages like C# and managed C++ are statically typed), the flexibility of VB lets it fill the gap in the dynamically typed compartment.

However, in some cases, when programmers are not completely aware of the effect that Option statements can have on the code, or when they are working with legacy code upgraded to VB .NET, they can produce potentially problematic code. Such code comes in two flavors:

• Code written in statically and strongly typed style, but without compiler enforcement of static or strong typing (Option Explicit Off and Option Strict Off but type declarations present)

• Code written in statically and strongly typed style, but without compiler enforcement of strong typing (Option Explicit On and Option Strict Off but type conversions not present)

In this chapter you are going to see in detail the effect that Option Strict and Option Explicit statements have on your code.

• You will see the benefits of strong static typing.

• I will show you ways to transform the problematic code, written in strong static style but without compiler enforcement, into code in which compiler checking is activated.

• You will also see how dynamically typed code can be useful in some circumstances.

• You will see how to combine statically and dynamically typed code in the same project, reaping the benefits of both styles.

• Finally, I will show you the alternatives you have when setting Option Strict and Option Explicit, and the role Visual Studio can play in this task.

... less

Error handling in software is similar to an emergency exit in real life. Nobody usually gives it too much thought, since... more

Error handling in software is similar to an emergency exit in real life. Nobody usually gives it too much thought, since you almost never use it. However, once you need it, you definitely want it to perform effectively. Emergencies and unexpected situations happen in software with more frequency than in real life, so the effect a badly handled exception can have on user confidence can be quite devastating. Nothing is more annoying for users than an application simply disappearing from the screen for apparently no reason at all, or receiving a number of cryptic messages instead of having tasks performed.

Error handling is an essential element of well designed and robust code. While it deals with atypical and unexpected situations, it is a crucial ingredient for providing a robust and reliable application. Successfully implemented error handling permits execution to resume without the application halting or crashing. It will give the programmer a chance to inform a user about the current state of the application in an understandable way, instead of showing some cryptic system messages. In some cases the user can be consulted on the way the application should continue. Coupled with logging, error handling can also be used to save the information on the state of the system when the error occurred, providing the programmer with valuable insight into the cause of the error and the location in the code where it occurred. This greatly simplifies debugging and maintenance.

In this chapter you are going to examine two different styles of error handling: legacy and structured. You will see why I prefer the structured style and how you can refactor legacy style into structured. Here is what I plan to talk about in this chapter:

• I’ll start by recapping how legacy error handling is implemented in VB. This style of error handling uses error codes and the On Error statement.

• Then I’ll take you through a look at structured error handling. Since it uses exception types instead of error codes, it is also referred to as exception handling. Structured error handling is realized through the use of structured Try-Catch-Finally blocks.

• After I compare the two styles, you’ll see how structured error handling is superior and why you should always strive to stick with this style of error handling.

• Since you are bound to come across code that is still making use of legacy error handling, I will demonstrate how you can convert legacy to structured error handling. You do this through two refactorings. The first one involves replacing the On Error statement with Try-Catch-Finally blocks and is accordingly called Replace On Error Construct with Try-Catch-Finally. The second refactoring you’ll deal with in this chapter replaces error code with exception type. It’s called Replace System Error Codes with Exception Type.

I want to start by taking a look at the different ways error handling in VB is implemented and how these styles compare.

... less

In this chapter you’ll continue to investigate preliminary VB refactorings. As I have already mentioned, you can generally... more

In this chapter you’ll continue to investigate preliminary VB refactorings. As I have already mentioned, you can generally perform these refactorings without any deeper understanding of the application problem domain, and they are mostly performed on the syntactic level. You’ll use them to prepare the code for more complex restructuring where application domain knowledge is indispensable.

• The first issue you’ll deal with in this chapter is dead code. Dead code comprises those sections of code that are left unused after some modification has been performed: a new feature is implemented, a bug resolved, or some refactoring performed. Dead code can have very negative effects on maintainability, and you will see the reasons why it should be eliminated.

• After that, I’ll remind you of the importance of well encapsulated code. Don’t forget, encapsulation is a pillar of well constructed object-oriented code. You will take a look at element scope and access level as mechanisms for hiding information and implementation details in your code.

• The next topic I’ll deal with is that of explicit imports. You can reference elements from other namespaces by using fully qualified names in code or by using the Imports statement. I will compare both styles and will explain why I prefer using the Imports statement.

• The last issue I’ll deal with in this chapter is that of unused assembly references. It is a good practice to eliminate these unused references as they appear, and you will see how the Visual Studio can help you do it.

With this, you will finish the exploration of preliminary refactorings. I hope that after you finish reading this chapter you will have a clear picture of code cleanness and hygiene, and of how to perform transformations to bring into shape any code that does not respect the rules.

... less

Programmers have in one sense a unique profession. It’s their job to analyze and understand the business of others. Often... more

Programmers have in one sense a unique profession. It’s their job to analyze and understand the business of others. Often they gloat over speed and algorithm effectiveness, forgetting that a program is only as good as the extent to which it fulfills its requirements and the client’s needs. Unless you are one of those programmers who prefer counting processor cycles to making your software purposeful and useful to others, you will agree that understanding the problem domain of your application is the first and most critical step in the process of software development.

This process is by no means trivial. You have to guide your clients in discerning the essential requirements from those that are superficial, in defining the rules of the business, and sometimes even in educating your clients about proven solutions in software design. While you are at it, you have to learn yourself and accumulate a compendium of knowledge on the problem domain you are dealing with. Finally, you use this knowledge not only to make your application work properly and fulfill user requirements, but also to make your code meaningful, establishing the links connecting the problem domain, the design, and the source code.

In this chapter you will see how these links are established.

• The chapter touches upon some general subjects like object-oriented analysis and design. You will explore a few analysis methods like use cases and textual analysis and see how these techniques can help you define the requirements your software must meet.

Note

One caveat: These are all very important concepts on their own, and this chapter will only tell you what you need to understand for our discussion of refactoring. So don’t take this chapter as a comprehensive guide on the subject.

• You will read about naming guidelines, why they are important and how refactoring can help. (And you’ll even revisit a naming convention well known to veteran VB programmers, Hungarian notation.)

• You will see some refactorings that can help you in closing the gap between code and problem domain, like the Rename and Safe Rename refactorings, which can help you eliminate smells like Unrevealing Names and Long Method. You’ll even get to hear a few words of VB trivia.

• Then I will talk about the difference between published and public interfaces. This difference is purely conceptual, meaning that you will not be able to use code to enforce it, but it has a great impact on the level and kind of refactorings you are allowed to perform on the code.

After this chapter is over, you will be much more aware of good practices that make code readable to humans. Taking into account that other people that will work on your code is not only altruistic, it is also an important part or what being a good programmer is all about.

... less

In this chapter we go back to the basics of object-oriented principles.... more

In this chapter we go back to the basics of object-oriented principles.

• You have certainly heard of encapsulation, but the benefits of encapsulation, like those of information and implementation hiding, are not automatically obtained, nor can you guarantee them by using object-oriented capable language.

• Then you will investigate the simplest form of encapsulation: a function. The same principles that can be used to improve function organization can be used with methods. You will see why long methods are problematic and how they can be improved by method extraction.

• After that, you will face the dark side of programming in its worst form: duplicated code. You will see how duplicated code is potentially disastrous and why you should try to avoid it. You will see how even simple refactoring such as Extract Method can do a lot to avoid code duplication. Sometimes duplication is so misused it turns into a real anti-pattern, or so-called copy-paste style. In this chapter you will start to learn how to reuse code much more effectively.

• Finally, you are going to take a look at one of the oldest ailments from which your code can suffer: magic literals. Fortunately, you are going to learn about the remedy and how magic literals can be replaced with constants and enumerations.

... less

In the previous chapter, you saw the benefits that can come from keeping the code granular and well encapsulated on the most... more

In the previous chapter, you saw the benefits that can come from keeping the code granular and well encapsulated on the most basic level, the method level. You also saw the importance of organizing the code in the form of small methods with well-chosen names.

When you come across long or poorly structured methods, the most common solution is to perform method extraction. You have also seen the mechanics behind method extraction, different illustrations of this refactoring, and how the whole process can be automated with the refactoring tool.

However, in the real world method extraction is seldom straightforward. If the method merits extraction, that means it was not well written in the first place, so you cannot expect that it will lend itself to extraction easily. Very often you will have to perform a number of preparatory steps to make method extraction meaningful. These steps may involve the following:

• Dealing with temporary variables that stand in a way of method extraction

• Regrouping statements so that blocks of code can be extracted in one step

• Dealing with temporary variable declaration and initialization statements

In this chapter you will see a number of refactorings that can be used as preliminary steps to method extraction. If you are able to apply these refactorings efficiently, you will be able to perform method extraction on even the most complicated and tangled methods.

... less

In theory, you could write programs in VB .NET without ever using a class or creating an object. Thanks to Visual Basic’s... more

In theory, you could write programs in VB .NET without ever using a class or creating an object. Thanks to Visual Basic’s legacy Module construct, you could write your programs in a procedural style without knowing the first thing about object orientation. In practice, such a style is rare, and to be honest I never come across it, except in some ad hoc and demo applications. However, misuse and poor design of objects are much more common. At the root of such code is a poor understanding of object orientation.

When designing an object-oriented system, you need to think of it as a system of communicating and collaborating objects. However, the step of converting analysis artifacts to object-oriented code is neither trivial nor straightforward and is often crucial for the project. While you have seen in this book so far that no change to code is impossible and no design decision is irrevocable, identifying the classes for the first time will establish the foundations of your design and will most probably lead the design in certain directions later on.

In this chapter, you’ll cover the following:

• I’ll start with a quick overview of object-oriented programming. This will help you understand the design techniques and refactorings I’ll talk about in this chapter in a deeper context. You will also see how there is more to encapsulation when you’re dealing with objects than when you’re dealing with functions.

• I will continue to discuss some topics I already touched on in Chapter 8 and Chapter 9. You will see how analysis artifacts like user stories or use cases serve as the basis for the design of the system. However, the gap between the code and the diagrams and text written in natural language is not easy to bridge. You’ll see some techniques you can employ in this endeavor.

• You’ll also see what to do if you stray along the wrong path in designing your code. All is not lost, and you can use diverse refactoring techniques to consolidate your design.

• You’ll see how to convert procedural or database-driven design to object-oriented design.

By the end of this chapter you will have a better understanding of object-oriented design as a dynamic, adaptable creation that can be modified to maximize code quality and to respond to changing requirements.

... less

In the previous chapter you explored some of the basic concepts in object-oriented programming theory. In this chapter you... more

In the previous chapter you explored some of the basic concepts in object-oriented programming theory. In this chapter you will work with some more advanced, but by no means optional, characteristics of object-oriented programming environments. These are the characteristics that put Visual Basic in the same league as other modern programming languages like C# or Java.

This chapter progresses as follows:

• First, you will see how you can employ inheritance, polymorphism, and genericity to further improve the design of your code, remove unnecessary duplication, and enhance encapsulation. These capabilities of Visual Basic are fundamental for implementing advanced reusability mechanisms and for the creation of frameworks and toolkit libraries.

• As you have seen many times in this book already, you won’t often reach optimal design during the first iteration of code. So in the second part of this chapter you will see how you can refactor your code by extracting classes and interfaces, moving methods up and down in the hierarchy, employing generic types, and so on. This way you will make use of these advanced object-oriented capabilities and thus take the design of your code to the next level.

• At the end of the chapter you will get back to the Rent-a-Wheels application. You will see how the number of classes in the application has increased substantially, but the overall complexity of the application and even the line count have been reduced.

• I will start this chapter by going back to some of the key concepts of object-oriented theory.

... less

Until now, I have hardly mentioned Visual Basic’s large-scale organizational mechanisms like namespaces and assemblies. The... more

Until now, I have hardly mentioned Visual Basic’s large-scale organizational mechanisms like namespaces and assemblies. The organization of your project and the partitioning of types to namespaces and assemblies can have a profound effect on the maintainability of your project and the development process in general.

Many of these issues are not apparent with small-size projects. They become much more relevant as projects grow and the number of types reaches hundreds or even thousands. Dependencies, on the other hand, are notorious to multiply with the age of project.

This does not mean that these issues should be taken lightly with smaller projects. Projects have a tendency to grow and decisions that you make early on can result in important consequences much later.

In this chapter, you will:

• See criteria that can be applied when using namespaces and assemblies to organize your project.

• Read about dependences and see why it is important to keep dependencies between different organizational units at bay.

• Take a look at file-level organization of code, partial types, and how all this affects forms inheritance in Visual Basic.

... less

Until now, I have promoted a rather simple approach to refactoring. You inspect the code, find the smells, and then refactor... more

Until now, I have promoted a rather simple approach to refactoring. You inspect the code, find the smells, and then refactor it so the smells are eliminated or at least reduced. This approach focuses essentially on negative aspects of your code in an attempt to eradicate them. Many times, following such an approach, you can reach an overall improved and even sophisticated design of your code.

It is also possible to lead your design toward some thought-out design goal. Often, such a solution is not immediately obvious nor the most simple. However, the benefits such premeditated design can bring often justify the added complexity.

To be able to lead your code toward some well-known design, you need to study and understand different design solutions. Design patterns were created with exactly that purpose, to share and disseminate knowledge on successful object-oriented designs that go beyond common and that capture the brilliance of sophisticated object-oriented solutions.

In this chapter you will:

• Learn what design patterns are and how to make use of them.

• Examine an example of a design pattern.

• Learn about the very influential Dependency Injection pattern.

• Apply refactoring to patterns concepts to the Rent-a-Wheels application.

Note

Refactoring to Patterns chapter caveat: Design patterns are a huge subject, and there is only so much that can be accomplished in the space of one chapter. More than to give you any practical knowledge on design patterns and refactoring combination, the purpose of this chapter is to instigate you in the right direction, to interest you in the subject, so you would learn more about design patterns and their application. As you learn more about patterns, you will recognize situations where they can be applied, and you will devise refactorings that will help you incorporate them into real-life, operational code.

... less

Visual Studio 2008 brings probably the most important version of Visual Basic since the first version of Visual Basic .NET... more

Visual Studio 2008 brings probably the most important version of Visual Basic since the first version of Visual Basic .NET. This is not because of the novelties in the integrated development environment (IDE) itself; more important are the new features that ship with version 3.5 .NET Framework and especially interesting for those involved in refactoring, Visual Basic version 9.0.

This chapter discusses the following features:

• LINQ technology brings additional power to working with data in Visual Basic. Different data sources can now be queried in a uniform and language-native manner. LINQ paves the way for implementation of different technologies like object-relational mapping frameworks and others.

• In the 2008 version, Visual Basic is additionally equipped for working with XML. Features such as XML axis properties and XML literals with embedded expressions make Visual Basic one of the best environments for working with XML.

... less

You have seen the current state of the art of Visual Basic programming and refactoring so far in this book. And in the previous... more

You have seen the current state of the art of Visual Basic programming and refactoring so far in this book. And in the previous chapter you have seen what the future holds for Visual Basic. It is time to make the circle full. In this chapter you will look back at the history of Visual Basic. You will see how refactoring can be relevant to dealing with significant and still existing code base of legacy Visual Basic code. In this chapter you will not see many new refactorings; however, you will see how you can apply already known refactorings to upgrade legacy VB code.

Pre-.NET versions of Visual Basic made VB during the 1990s the most popular programming tool on the planet. The simplicity and power of Visual Basic, promoted under the Rapid Application Development (RAD) concept, won the sympathies of a multitude of developers who needed a no frills tool for instant results.

The success of classic Visual Basic (VB 6 and previous) and its loyal user base proved to be one of the biggest hurdles for adoption of Visual Basic .NET. Many VB 6 programmers were content with their tool and decided to keep using it. This decision was further fueled by two characteristics of VB .NET:

• VB .NET brings a significant rupture in syntax and other language characteristics (object-oriented versus object-based, and so on) compared to classic VB.

• Classic VB code is not easily migrated to VB .NET.

I will not take part in the Visual Basic .NET versus classic Visual Basic debate, because I consider it to be in the area of each programmer’s personal preferences. There is no doubt, however, that VB .NET is now a better choice in a commercial and technological sense, and more and more programmers and organizations are switching from classic VB to VB .NET or some other language like C# or Java.

Are Classic VB and VB .NET the Same Programming Language?

VB .NET is an evolution of VB 6 programming language, and this is reflected by the versioning policy that Microsoft applies to the Visual Basic language. The first version of VB .NET is also known as VB 7 while the version that ships with Visual Studio 2008 is known as VB 9.

However, changes introduced in the first version of .NET when compared to VB 6 mean that there is no backward compatibility between the two. If you compare this to the relationship between the C and C++ programming languages, you will see that almost any C code can be compiled with a C++ compiler, making C and C++ in that aspect more closely related than VB and VB .NET. New language capabilities like full object orientation and metadata in the forms of attributes, generics, and so on, require a significant paradigm shift from the programmer’s point of view. That is why when embarking on Visual Basic .NET and coming from classic Visual Basic, you are better off viewing VB .NET as completely new programming language that deserves thorough study, practice, and significant assimilation time.

Unfortunately, the migration process from VB 6 to VB .NET is by no means smooth. In case you still haven’t started with migration, you are certainly considering it. This chapter starts by dealing with the following question: should you migrate from VB 6 code to VB .NET?

Note

This chapter deals mostly with VB 6 legacy code, because the VB 6 code base is probably the largest of all pre-.NET Visual Basic versions. If your code is pre-VB 6, then you will have to put additional effort into migration, more so the older your code is. In addition, you will not be able to count on the help of the Upgrade Wizard.

... less

Thanks to its partnership with Microsoft, Developer Express has released Refactor! for VB, a free and scaled down version... more

Thanks to its partnership with Microsoft, Developer Express has released Refactor! for VB, a free and scaled down version of their Refactor! Pro product. The free version has several limitations:

• It supports only the Visual Basic programming language.

• It works only with Visual Studio 2005 and 2008, while the Pro version works with Visual Studio 2002 and 2003 as well.

The Pro version lets you extend the capability of the tool and define your own refactorings, it has code analysis capabilities, more refactoring options, and so on.

There is one more limitation. Configuration options are visible only in the Pro version of the tool by default. However, with a little bit of tweaking, you can make a DevExpress menu item appear and obtain access to Refactor! options window even with the VB version!

... less

This appendix extends the scenario from Chapter 4 by investigating the implementation of Rent-a-Wheels application prototype... more

This appendix extends the scenario from Chapter 4 by investigating the implementation of Rent-a-Wheels application prototype in more detail. It continues recounting the conversation between Tim, the novice VB programmer who worked up the first version of the prototype, and me, focusing on two main areas of the prototype application:

• Relevant event-handling code

• Relevant form class code

Note

Remember, this code is not meant to illustrate good design principles, but quite the opposite. It is here to illustrate a non–object-oriented, legacy VB approach to Rapid Application Development (RAD). Try to think about better ways to implement this application. Compare your ideas with the solutions that I offer throughout the book while refactoring and improving the Rent-a-Wheels prototype.

... less