Hgeocities.com/Baja/Dunes/7592/vbcc4.htmgeocities.com/Baja/Dunes/7592/vbcc4.htm.delayedx MJo*OKtext/htmlg*b.HFri, 10 Jul 1998 01:16:18 GMTMozilla/4.5 (compatible; HTTrack 3.0x; Windows 98)en, * MJ*

Visual Basic Naming Conventions

Page 4

Previous Page | Home Page | VB Page | Next Page
Coding Conventions
This section contains several conventions that should be useful when writing code. They are by no means comprehensive, but should nonetheless be seriously considered in development. This section will continue to be developed in order to obtain a complete development guide. The Changing Your Approach subsection talks about four very important rules that you can follow that help you take advantage of VB5's object oriented capability. The Principles subsection gives smaller and more specific suggestions on coding style.

Changing Your Approach
There are three rules (so far) that you can quickly apply to your coding style that will quickly improve its quality. These rules are also a simple way to force yourself to take advantage of VB5's Object Oriented Programming capability. These are not necessarily in order of importance, but number one is, in my opinion, extremely important and simple to implement. Some of this information may be repeated in the Principles subsection.

1. Do not use global variables.
This means literally NO global variables. Understanding class modules and the (finally) ability to treat forms as objects in VB5 makes it unnecessary to have any global variables. Why not? Well the short answer is that global variables create a possible dangerous interdependency between different parts of your program. They are also difficult to trace properly. If you need to share information between objects or forms, make that information a property or method of your object, do not use a global variable. A global variable is easy to define and use initially, but they ALWAYS create more problems then they solve in the long term. Some applications have a particular functionality that may seem to lend itself to a small number of global variables. An example of this could be a global instance of a User class. This could be seen as acceptable because the nature of this variable is truly global, in the sense that it could be needed in every part of the application. For the most part, you should never have more global variables than you can count on one hand.

2. Do not use user-defined types.
This means anything with the Type statement in it. These structures were quite effectively replaced by classes in VB5. If you have something that is a candidate for a user-defined type, then it is a candidate for a class. Besides classes are more powerful and FUN! There is one exception to this rule, that is if you are calling a DLL that requires a structure.

EDITOR'S NOTE:
There are certain exceptions to the above, you make want to use user defined types to write structures to binary files using the Get and Put statements. ----O.C.

3. Do not pass function parameters by reference.
Unfortunately, the default way in which variables are passed in Visual Basic is by reference. Prefix all of your sub and function parameters with the keyword ByVal. There are a million reasons not to pass by reference, but mainly it is very hard to trace a bad value if a called procedure is (knowingly or unknowingly) modifying your variable in memory.

Principles
Write your code for the reader. In rapid application development clarity is more cost effective than efficiency. Understanding efficiency is important, and should serve as a guide in your coding, however clearly written and documented code is easier to understand and maintain. By today's standards, processing cycles are extremely inexpensive, so highly efficient and cryptic code can cost more in the later phases of the development life cycle. Here are some high level guidelines:
Page 4

Previous Page | Home Page | VB Page | Next Page