You’ve done it! You’ve completed the Library Project and met with acclaim from users and fellow programmers alike. And you’ve also accomplished something that few thought was possible: You slogged through all 25 chapters of this book. You’re probably anxious to get on with your life as a highly-paid software consultant, working just six months per year as the programmer who other programmers call when systems fail. Well, I won’t keep you too long. But there are a few more issues to discuss concerning the Library Project and programming in general.
The Library Project is filled with features that target small library-style organizations. But it may not meet the needs of everyone. And that’s okay. The users know your address and phone number; you’ll hear from them. When they call, you can tell them that the software wasn’t designed for everyone; no software can be. All software, even general-purpose applications such as Visual Studio, can never meet the needs of every person or organization. What is important is that the features included in the project meet the needs of the intended audience. That audience may be the card-catalog-using public, or it may just be a small library with one part-time staff member.
Still, there is always room for improvement. Because the Library Project’s real target audience was you—the student of Visual Basic and .NET—it did not have all the features that most libraries would require. Looking quickly back through the source code, I came up with at least the following changes that could be made to the project to bring a lot more value to library administrators and users.
These are just some of the improvements that I thought of off the top of my head. If I had gone all the way down to my shoulders, I could have come up with even more. If your software will target the general population of users, you will probably release updates on a regular schedule, such as annually, and charge appropriately for the improved features. If you wrote the application for one specific customer, the updates may be more frequent, even weekly or daily in some cases. Whatever the audience size, your opportunities to improve and enhance the software will be regularly and ongoing.
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 be—well—older.
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.
As you enter deeper into the world of software development, you will quickly discover that the application-building process is about much more than syntax, statements, and logic. It is also about who you are as a programmer. The way you think about software, and the care with which you approach the task of programming, have a direct impact on the quality of the code you write. This is certainly true in other areas of life. If you are a portrait painter, but you don’t take your strokes seriously, or if you are sloppy in your use of paints and brushes, it will show in the low quality of your work.
In one of my previous books, The Visual Basic .NET Style Guide (Upper Saddle River, NJ: Prentice Hall Professional Technical Reference, 2002), I wrote about three traits that provide a strong basis for the programming life, as follows:
If you are deficient in any of these three areas of your programming life, your applications and code will also be deficient by a similar factor. I have tried to sprinkle some humor and fun throughout the pages of this book. But on this point, I make no jokes. You need these three elements in your work life.
If you are serious about a career in software development, take the time to ask yourself questions that focus on these three aspects. Do I employ regular discipline on the way that I craft my software? Do I create reasonable and reliable plans, and then stick to them during a project? Do I exhibit ethical standards in the way I communicate with my customers, my employer, my coworkers, and even myself? If you are not able to answer these questions to your satisfaction, find resources that can help you overcome the lapses. It will make your programming work so much easier, and it will positively impact the other areas of your life as well.
Now you’ve really reached the end of the book. You can read through the appendices and the index if you’re still hungry for more. But a better solution would be to find out if I’ve come out with the next edition of the book and buy it. Ha!
I thank you for taking the time to read through Start-to-Finish Visual Basic 2005. It was written so that you might expand your understanding and expertise of a very practical and very enjoyable subject: Visual Basic. And “enjoyable” is the key word. Nobody has to be a computer programmer, no matter what historians say. You should take on the role of a Visual Basic developer only if you truly take pleasure in helping other people become more productive through specialized or general software. If, even after reading this book, you find coding to be a bore and sheer drudgery, I recommend the food services industry as an alternative.
For those of you still excited about Visual Basic programming, have as much fun with it as possible. Microsoft is constantly updating the language and its Visual Studio shell so that you can really enjoy yourself as you program. Why do you think they put in all of those animation features? Take time to go beyond the mundane in your code and in your user interfaces. Challenge yourself by trying out new features within the language and in the Framework. And above all, smile each time you successfully complete a project. Your author, and your users, will thank you.
18.227.72.131