Why This Book Is Necessary

Microsoft Visual Basic has the largest user base of any development language in the world, and the ranks are growing. Estimates put the number of users of Visual Basic at about 3 million. Once considered a hobbyist's language, Visual Basic has quickly gained the respect of serious developers and is now widely used in corporate and other commercial environments. Visual Basic .NET further raises the bar, as it now shares the common language runtime used by Visual C# .NET and other Microsoft .NET languages. It also shares the same IDE, debugging tools, and much more. In the past, there were many arguments about the utility of Visual Basic in building enterprise solutions. Much of this debate pitted the RAD attributes of Visual Basic against the power attributes of C++. Visual Basic was capable of doing amazing things, but often you had to resort to API calls and third-party components to get "under the hood" of Microsoft Windows. Now, the playing field is truly level. Visual Basic .NET's generous flexibility, combined with its focus on maintaining backward compatibility, has always made it an extremely powerful language. Unfortunately, these attributes also seem to encourage sloppy programming, and that simply won't do in today's fast-paced development environments.

For example, Visual Basic .NET will actually let you create what I call voodoo variables. A voodoo variable is a variable created on the fly simply by its name being referenced. If you haven't included the Option Explicit statement in a module or set it at the project level, you can create a voodoo variable by referencing the name of a variable not already declared or in use. Voodoo variables are often created by mistake, and they can be very difficult to debug. Visual Basic .NET shouldn't even allow you to turn off the requirement to explicitly declare variables. This feature is available for backward compatibility, but it has no place in modern programming not in applications written for fun and certainly not in distributed applications.

Many developers have been getting by with sloppy code for years, either their own code or the code of someone on their team. The repercussions of poor programming techniques are numerous. For example, have you ever needed to make a small change to a procedure and ended up having to rewrite the entire procedure because the code wasn't easily modifiable (extendable)? When processes are cobbled together in a routine, they tend to make enhancements and modifications difficult, if not impossible. Correctly written code, on the other hand, is generally much easier to modify as the need arises.

Have you ever had to modify someone else's code and discovered that you needed hours, days, or even weeks just to understand how certain processes worked? Have you ever revisited your own code after some time has passed only to find that you weren't very generous with your comments and you can't remember exactly how you implemented the processes? When you're forced to deal with your own sins, the benefits of standards become much more obvious. Code written to strict standards contains sufficient comments to make it easy to understand what is occurring in a procedure as well as how the tasks are being accomplished. The visual presentation of the code, such as its indentation and use of white space, and the proper naming of variables can also make code dramatically easier to understand.

Many developers still don't give enough thought to the data types of their variables. This problem ranges from using the Object type when it's not necessary to using the Single data type where Double is required. In these situations, it's possible for Visual Basic .NET to perform type coercion or unanticipated rounding, giving you unexpected results. For example, if you put a number with a decimal value into an Integer variable, the value is rounded but no error occurs. If, however, you attempt to put a value into a variable larger than its data type allows, a run-time error occurs. At design time, it's almost impossible to test for some of these conditions without putting huge amounts of test data through the program. You need to define variables correctly from the beginning, or problems won't be known until they start manifesting themselves on your customer's computer. Visual Basic .NET includes a new setting called Option Strict, which enforces strict variable declaration and usage and should be turned on whenever possible. However, using Option Strict requires some dedication as it necessitates more code (and more thought); the benefits, however, are worth the effort!

Performance is always a top priority for developers. So, although computing horsepower is climbing at a phenomenal rate, you should remember that not everyone is using equipment like the state-of-the-art development machine you have under your desk. Code written to meet certain standards, such as strict data typing and the use of the proper loop for a given task, often runs faster than code that doesn't meet those standards.

Another consequence of not adhering to proper coding standards affects you, the developer, alone: you might not get and you might even lose a job because of lax coding. As an employer of Visual Basic programmers, I've found that most of the applicants I've chosen not to employ were disqualified because of their code, not their resumes. I review code samples of every developer that applies to work for our company. The most common problem code that lacks liberal and accurate comments is often just the tip of the iceberg when it comes to bad code. What I've seen is truly amazing and often pitiable. I've reviewed code in which not a single variable was explicitly declared there were voodoo variables everywhere! I've even reviewed code in which all the variables were declared at the module level. Out of curiosity, I performed searches on some randomly chosen variables. Most were used in only one procedure. Many weren't used anywhere! When I queried the author of the code about this, he informed me that he felt he might need those variables in the future, so he was just planning ahead! If none of this sounds like weak programming practice, this book should prove valuable to you indeed.

If you think that I'm being picky, you might be right. However, I can tell you that I'm not alone. Many people realize that someone who writes good, sound code that adheres to solid programming standards can learn to code just about any process. If you're looking for a job, take the principles in this book to heart and modify your code before sending it to a potential employer for review.

As I've said, Visual Basic's power and flexibility, coupled with its built-in allowance for backward compatibility (admittedly much less in Visual Basic .NET than in previous versions), create numerous problems. These problems multiply when you consider that a large number of Visual Basic programmers are self-taught, lacking the formal development training that would help them recognize the pitfalls of bad programming techniques. Visual Basic .NET is a new language, different from all previous versions of Visual Basic make no mistake about it. You simply can't get away with some of the hacks and shortcuts that you could with previous versions. These facts make the need for published standards all the more necessary.

Although applications developed with standardization techniques have been shown to contain fewer errors, to be easier to maintain, and to be easier to enhance (this just can't be said enough), some programmers argue against standardization. Unfortunately, such arguments often originate in arrogance, a lack of understanding, resistance to change, or simple laziness. For example, claiming that it requires too much effort to add a three-character naming prefix to a variable to denote its data type is like claiming that it takes too much typing to call a variable TotalStudents rather than calling it X. Sure, typing X is easier than typing TotalStudents, but who can argue that the time savings is worth it when you consider the later confusion created?

Note

Fewer topics, it seems, invoke more polarization amongst developers than the use of Hungarian notation (naming prefixes). This debate will only continue to heat up now that Microsoft is recommending dropping the use of Hungarian notation. I've surveyed a number of developers and trolled many newsgroups, and it seems that most developers plan to continue using Hungarian prefixes because they believe them to be an important part of their development efforts. The good news is that you can continue to use Hungarian notation in your projects and yet still conform to the spirit of the .NET framework design guidelines at the same time. I swear by naming prefixes, and therefore I recommend them as well as use them in this book. In Chapter 3, "Naming Conventions," I discuss the use of Hungarian notation in great detail including doing my best to make a case for them. If you're one of those developers in the other camp the one that hates prefixes, I say "to each his own" and I ask you to please overlook the use of prefixes throughout the examples in this book.

 

The benefits of standards multiply as more developers are added to a project, and therefore it's often the corporate and commercial shops that make the first attempts to standardize. In development shops using some level of standardization, the standards employed usually come from a high-level manager, someone who has to review and maintain code written by others. However, the standards used are often a small subset of those that should be employed, and often they're standards created internally, comprising many unique characteristics rather than universally adopted techniques. When hired at such a place, a developer might be forced to learn development techniques that differ greatly from those already familiar to him or her. This, of course, adds unnecessary work and increases the possibility of error.

Every person who writes code should employ some common standardization techniques even when writing only a few lines of code. The need for standardization increases exponentially as the number of developers who work on the code increases and the number of lines within a program increases. Whether you're a hobbyist or a corporate or commercial developer, standardization techniques should be part of your base set of skills.

At my company, we did an analysis a long time ago and discovered that we were using a hodgepodge of standards each developer was doing essentially whatever he or she wanted to do. I know what a long road it is to universally adopt standards in development because I've traveled it. It's not easy, but it's worth it.