Why This Book Is Necessary

[Previous] [Next]

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, it has quickly gained the respect of serious developers and is now widely used in corporate and other commercial environments. Visual Basic's generous flexibility combined with its focus on maintaining backward compatibility make it an extremely powerful language. Unfortunately, these attributes also seem to encourage sloppy programming.

For instance, Visual Basic 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, 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 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. To make matters even more difficult, when you install Visual Basic the default settings do not require variable declaration. If you don't know to turn on this feature, you're creating potential land mines in your code.

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 variants where they aren't necessary to using the Single data type where Double is required. In these situations, it's possible for Visual Basic 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.

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 on your desk. Code written to meet certain standards often runs faster than code that doesn't meet those standards, such as strict data typing and the use of the proper loop for a given task.

Another consequence of not adhering to proper coding standards affects you, the developer, alone: you may not get and you may 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 problemcode that lacks liberal and accurate commentsis 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 declaredthere 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, 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. 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 enhancethis just can't be said enoughsome 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?

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 the developer. 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 standardseach 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.