Practical Standards For VB.NET

MS 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 MS .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 MS 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.

TABLE OF CONTENT:
Chapter 01 - Creating Object and Project Templates
Chapter 02 - Designing Modules and Procedures
Chapter 03 - Naming Conventions
Chapter 04 - Using Constants and Enumerations
Chapter 05 - Variables
Chapter 06 - Formatting Code
Chapter 07 - Commenting Code
Chapter 08 - Looping Structures
Chapter 09 - Controlling Code Flow
Chapter 10 - Exception Handling
Chapter 11 - Programming Objects
Chapter 12 - File Operations
Chapter 13 - Debugging
Chapter 14 - Interface Design
Chapter 15 - User Input and Notification
Chapter 16 - Distributing Solutions
Chapter 17 - Version Control
Chapter 18 - Source Code Control

Download Here

Password:ganelon