I started using Visual Basic back when version 2.0 of the product was still in vogue. As a result, I picked up some pre-.NET coding habits that have been hard to break, even with my full-time focus on .NET code. I've reached a level of comfort in my Visual Basic coding, and that comfort shows in my .NET coding style.
As I mentioned in earlier chapters, many of the features that previously existed in Visual Basic before .NET were moved out of the language and into Framework classes. The most noticeable of these were the mathematics features now found in the System.Math class. But there were other non-math Visual Basic language keywords that also became class methods. Many of these appear in the Microsoft.VisualBasic namespace, including methods such as Left, Trim, and MsgBox.
When I wrote the Library Project code, I freely used some features found in the Microsoft.VisualBasic namespace. Although I don't have a problem with this practice, you may encounter other Visual Basic developers who don't agree with how I've written the code. They point out that most, and possibly all, of the features in Microsoft.VisualBasic have Framework Class Library equivalents, and these should be used for reasons of compatibility with other .NET languages and systems.
A key example is the MsgBox function. I've used it throughout the Library source code. The keyword MsgBox has always been a part of the Visual Basic language, but beyond its continued existence in Microsoft.VisualBasic, it is not a part of the Framework classes. Instead of MsgBox, other programmers (including C# programmers) use the System.Windows.Forms.MessageBox.Show method. It does offer more options than MsgBox, and it displays a message box that is every bit as beautiful as the Visual Basic version. But for me, my fingers have gotten used to typing the short six-character MsgBox keyword. (MessageBox.Show has 15 characters!) Also, the arguments passed to MessageBox.Show are slightly rearranged from those used in MsgBox. Using both of them in a single program could result in some confusion.
Supporters of MessageBox.Show emphasize that if you ever needed to convert Visual Basic code to C#, the presence of MsgBox would slow down the conversion. Although I understand this and other concerns, I have not yet been fully convinced that there is any problem using MsgBox. Any conversion tool that existed to change Visual Basic code into C# would certainly know how to handle MsgBox.
As another example, consider the older Exit Sub statement. It still exists in Visual Basic for .NET, but the new Return keyword performs the same job of immediately exiting from the current method. (Return had a different meaning in Visual Basic before .NET, but now it only exits methods.) You can use either Exit Sub or Return in your code; they are identical in functionality. There are programmers who consider the older Exit Sub statement to bewellolder.
But unlike my reticence to leave my favored MsgBox method, I have wholeheartedly embraced the new Return statement. If it was just an issue of Exit Sub versus Return, I might not have made the switch. But there is the related issue of Exit Function versus Return. I was never happy with the way that pre-.NET Visual Basic functions obtained their return values through an assignment statement to the name of the function. I was ready to make the switch to the newer Return statement. I did so for clarity; keeping the return value as close as possible to the statement that triggers the return to the calling code is a good thing. Before .NET, you might assign the return value, and then not leave the function for dozens of lines. Combining the assignment and the return in a single statement makes sense to me. From there, it was a short trip to replacing Exit Sub with Return. You will not find (I hope) a single Exit Sub statement in the Library Project. My transformation in this area is complete.
Why do I bring all this up? I do it to encourage you to make flexibility your friend when it comes to the different coding variations that exist in Visual Basic. If two different ways of developing a block of code seem to be morally equivalent, and you can make the logic clear no matter which method you pick, then choose and enjoy the coding style that you are most comfortable with. Some programmers may tell you to do it one way or another, and that's okay. (If you are part of a development team, the entire team should agree on a common style.) Remember that Visual Basic is a "general purpose" programming language, and it has a certain amount of flexibility built into the language and related features. Experiment with the variations, and find patterns that you enjoy and that increase your effectiveness as a developer.