Share this:


VISUAL PROGRAMMING

Visual Basic Coding Standards (VBCS)

WHY HAVE CODING CONVENTIONS

Visual Basic design and coding conventions are important for a number of reasons:
· Software is read many more times than it is written, often by someone other than its developer.
· Coding conventions increase the readability of the software, permitting software engineers to understand and maintain software more quickly and correctly.
· From 70% to 90% of the cost of software is in maintenance rather than development.
· The original developer will rarely maintain any software for its entire life.
· Software is a critical part of our products; it should be just as well engineered, packaged, and documented as our hardware.
· Providing standard coding conventions permits the developer to concentrate on more important issues such as design.

DEFINITIONS

A convention is one of the following:
· A standard (S) is a mandatory constraint on the content or format of something (e.g., code, documentation). You must follow standards unless you obtain a waiver from the Process Team and you document the deviation from the standard.
· A guideline (G) is an optional constraint on the content or format of something (e.g., code, documentation). You should follow guidelines in most cases. You must document any deviation from the guideline.
· A recommendation (R) offers advice. It is less constraining than either a standard or guideline. You may follow or ignore recommendations as appropriate. You need not document any deviations from recommendations.
Visual Basic (VB for short) refers to any programming environment, which uses a Visual Basic-like language. The standards in this document apply to these other environments, as well as Visual Basic itself:
· Visual Basic for Applications (VB A), used in Microsoft Office products
· Visual Basic Script (VBScript), used in Active Server Pages and in MS Outlook
· LotusScript, used in Lotus Notes.
A module is a block of code (declarations and procedures) which VB stores in a single file. Forms, Classes, UserDocuments, and Code Modules will all be referred to as modules in this document. In L
otusScript, each object (Agent, View, Form) may be considered a module. In VBScript, each file may be considered a module.
Procedure refers to a Sub, Function, or Property Let, Get, or Set function.

USAGE GUIDELINES

The following sections provide standards and guidelines for the general usage of Visual Basic. These standards ensure consistent usage of various Visual Basic features.

OPTION STATEMENTS

S) Use Option Explicit. Option Explicit should be included at the beginning of each module to enforce explicit declarations for all variables. In the VB environment, the option to “Require Variable Declaration” should be set. This tells VB to include Option Explicit in all new modules.
Rationale: When variables can be instantiated on the fly, typographical errors in variable names are not caught by the compiler and can cause run-time errors.
S) Do not use Option Base. The default lower bound of 0 (zero) should be used for arrays; do not use Option Base to change it. If a different lower bound is needed for an array, explicitly define both the lower and upper bound of the array in the Dim or Re Dim statement.
Rationale: Most programmers will assume that the lower bound of arrays is 0. A change in the lower bound will not be apparent to someone in the middle of reading the code. But this will not be apparent to someone
Example:
‘* Array from 0 to 10, using default lower bound.
Dim a Words(10) as String
‘* Array from 1 to 12, both bounds explicit.
Dim a Months(112) as String

DECLARATIONS

The following conventions help you build good abstractions that maximize cohesion:
S) Use narrow scoping. Use private variables and constants whenever feasible. Local (procedure-level) variables are preferred, followed by module-level, with global as a last resort.
Rationale: Increases cohesion.
S) Declare module level variables in this order:
1. Public API Declarations
2. Public Constants
3. Public Types
4. Public Variables
5. Private API Declarations
6. Private Constants
7. Private Types
8. Private Variables
Rationale: A consistent declaration order makes the module header easier to scan. The prescribed order provides clear separation between Public and Private declarations, and suggests an appropriate dependency between Constants, Types, and Variables.
S) Declare scope explicitly. Use Private and Public, instead of Dim, for variables declared outside of procedures.
Rationale: VB has different defaults for each type of code module (form, class, etc.). Explicitly declaring the scope of variables reduces confusion.
R) Declare variables and constants at the beginning of their applicable scoping construct (module or procedure). VB allows you to declare variables anywhere within a module or procedure, but they should be placed at the top.
Rationale: This makes declarations easy to view, and avoids cluttering up the flow of executable code. Usually the rationale for putting the declarations in the middle of the executable code is that it declares variables near the point where they are used. But this is only important if procedures are allowed to grow beyond a manageable size. If a block of code is independent enough to require its own variables, it belongs in a separate procedure.
S) Use explicit types. Each variable should be declared with an explicit type, to prevent VB from creating all variables in the Variant type. If Variants are needed, they should be declared explicitly As Variant.
Rationale: Variants should be avoided because they are less efficient than defined types, and because their use prevents VB from catching errors through type-checking.
Exceptions: The VBScript environment only supports Variant types, and does not allow you to declare a variable as an explicit type. In VBScript, comments and naming conventions should be used to inform the reader as to the intended use of the variable.
T) Use narrow typing for objects. Don’t use an Object type when the true type of the object is known. For example, if a variable contains a reference to a Text Box, the variable should be declared As Text Box, not As Object or As Control
Rationale: Narrow typing makes the true purpose of the variable more obvious. It also allows VB to catch type mismatch errors at compile time, and execute more quickly at run time through early binding.

ERROR HANDLING

The following conventions help you to handle errors effectively:
R) Include error handling in every event procedure. Each event procedure should have an On Error statement as its first executable statement.
Rationale: In VB, unhanded errors result in termination of the program. Since all code is executed as the result of an event, event procedures represent the last chance to handle errors, which bubble up from other procedures.
R) Include error handling in every procedure where errors are likely to occur. This includes any procedure that performs I/O, database functions, operating system calls, COM operations, or invokes methods on other objects. Errors should be handled in the same procedure where they occur.
Rationale: Localized error handling increases cohesion, and allows you to
provide error handling specific to the types of errors that are likely to occur. The farther that a project-specific error bubbles up, the less likely that it will make sense to the procedure that must handle it.
R) Use common error trapping label names. Use the same label name (for example, “Err-trap”) in all procedures
Rationale: This improves the consistency and readability of the code.
Example:
Sub cmdOK_Click
On Error Go to Err-trap
‘* … More code here …
Exit Sub
Err-trap:
MsgBox “Error “ & Err.Number & “: “ & Err.Description & “ in “ & Err.Source, vb Exclamation, App.Title
End Sub

TESTING

R) Use Debug.Print Statements. Print the value of variables to help confirm intermediate results and confirm that code is executing as expected. Debug.Print statements are ignored when the code is compiled
Rationale: Makes code verification and debugging easier.

SOURCE CODE FORMATTING

The following standards provide a consistent look and feel to the Visual Basic code and improve its design.

CODE ORGANIZATION

The following conventions will help to ensure that the code is organized into easy-to-understand pieces.
R) Keep modules to a manageable size. Each module should be less than about 1000 lines, and contain a set of procedures that are related to each other. If a module is becoming larger than 1000 lines, consider splitting it based on some functional criteria.
Rationale: Small, cohesive modules are more manageable and easier to understand. They also reduce sharing conflicts in version control tools.
R) Avoid putting general code in Form modules. Form modules (and other modules with a visual interface) should contain only the event procedures for the form. Procedures called by the event procedures should be placed in other modules unless they deal directly with many of the controls on the form itself.
Rationale: Form modules tend to grow large through their event procedures and visual interface definitions. Moving other code into other modules will help to keep Form modules small and focused on their main purpose, which is interacting with the user.
Because Forms consist of both binary and textual components, they are not handled as well by version control tools. Keeping code in other modules minimizes conflicts.
R) Keep procedures to a manageable size. Each procedure should be concise enough that its entire purpose can be easily expressed and understood. One rule of thumb is that the well-commented procedure should fit on a printed page. A more relevant rule when editing the code is that it fit on one screen in the development environment.
Rationale: Small procedures are easier to understand and verify.
Exception: A single control structure (for example, a Select structure) may be unavoidably longer than the recommended procedure length. In this case, the control structure should be placed in its own procedure, separate from other code, so as not to obscure the function of the code around it.

INDENTATION

G) Use the standard indentation provided by Visual Basic tabs. The VB environment provides tools that make it easy to indent blocks of code by tab stops.
Rationale: Indentation improves readability. Using the standard tab-stop indentation improves maintainability, allowing the indent level of blocks of code to be easily changed.
Exception: LotusScript indents automatically, and does not support tabs.
G) Use four spaces for each indent level. The default tab spacing of in VB is four spaces, and this should be maintained.
Rationale: Four spaces is enough to make the indentation level obvious, without taking up too much horizontal space.
Exception: LotusScript indents automatically

SPACES

R) Apply spaces liberally.
Rationale: Spaces break up the code, making it easier to read.
Example 1:
void some Method (TypeX aTypeX, TypeY aTypeY) throws Some Exception;

MAXIMUM LINE LENGTH

G) Avoid lines longer than 80 characters.
Rationale: Longer lines are more difficult to read. Also, many terminals and tools do not handle longer lines well.
G) Break up long procedure declarations on to multiple lines with each parameter aligned.
Rationale: This makes the code much easier to read and makes it less likely that maintenance will introduce new bugs.
Example:
Function Collect Stats(sFileName As String, _
iStartLine As Long, _
iEndLine As Long) _
As Long
G) Limit method and object reference cascades to three levels.
Rationale: Method cascades can be hard to understand and can be the source of synchronization and exception handling problems. It slower to execute statements using multiple cascades. Visual Basic must traverse the object hierarchy from the top for each statement, so it is more efficient to assign a variable to a lower-level object if it will be used for multiple statements.
Acceptable Examples:
returnValue = anObject.method1().method2()
returnValue = anObject.method1().method2().method3()
oSelection = Word.ActiveDocument.Selection
i Start= oSelection.Start
Not Acceptable Example:
returnValue = anObject.method1().method2().method3().method4()
Word.ActiveDocument.Selection.Font.Bold = True

BLANK LINES

S) Put a blank line between logical sections of a procedure.
Rationale: This improves readability.
Example:
Sub Process Data()
Check Precondition
Do Foo
DoFam
Check Post condition
End Sub
Comment: If the method is long or violates other standards, it should be factored based on the logical sections described above.

COMMENTS

The following Visual Basic comment standards provide a consistent approach to documenting code that will also improve the quality of the associated java documentation.

COMMENT FORMATTING

R) Begin comments with ‘* (an apostrophe, an asterisk, and a space). All VB comments start with an apostrophe and end with a line break. This convention adds an asterisk and space before the actual comment text.
Rationale: When viewing VB code, the apostrophe alone does distinguish the comment well from the code. The asterisk and space improves legibility by setting the comments off more clearly.

MODULE COMMENTS

S) Write a comment block at the top of each module. The comment block will include the name of the module, a description its purpose, its authors, and its revision history. It should also contain version and copyright information, if appropriate. Each entry in the revision history will include the date that the change was made, the author who made the change, the reason that the change was made, and a list of the procedures affected.
Rationale: Module-level comments help future programmers to understand and respect the purpose of the module, and to consider the potential impacts before making revisions.

PROCEDURE COMMENTS

S) Begin each procedure with a comment block. The comment block shall immediately follow the declaration of the procedure, and contain a description of the procedure, including the reason why it is needed. Following that should be a list of the per- and post conditions necessary for its operation, a description of its parameters and return value, and possible errors which may occur.
Rationale: Well-commented procedures make the code easier to understand.
Example:
Function Check Spelling(text Comments As VBA.Text Box) As Boolean
‘* Run the spell checker on the textbox. This prevents
‘* spelling errors from being stored and displayed to the
‘* customers.
‘* Preconditions: Textbox has been filled
‘* Post conditions: The data in the textbox may change if
‘* spelling corrections have occurred
‘* Parameters:
‘* text Comments – Text Box containing free-form text
‘* Return Value:
‘* Boolean indicating whether spelling errors were found.

DECLARATION COMMENTS

G) Describe the abstraction of all declared constants, types, and variables, the meanings of which are not obvious from the name. This includes both module- and procedure-level declarations. Also, describe any constraints of the variables.
Rationale: This will make the code easier to understand and maintain.
Example:
Dim previous As Long ‘* Previous cursor position
‘* (0..MAXPOS)

GENERAL COMMENTS

G) Do not comment obvious code. If the code is not obvious, then first see if you can rewrite the code so that the use of comments will be unnecessary.
Rationale: This will make the code easier to maintain.
Bad Example:
Dim i Connection Count As Long ‘* number of connections
G) Where practical, line up trailing comments.
Rationale: This will make the comments easier to see, compare, and maintain.
Example:
If Not Data Ready() Then ‘* precondition fails
Error 30005, “Data not available”
Else ‘* normal case
Process Data
End If
S) Use proper spelling, punctuation, and spelling in comments.
Rationale: Poorly written comments are distracting and can obscure the intended meaning.

MODULE NAMES

S) Module names should be meaningful words or phrases that describe the abstraction of the module. Use nouns for object abstractions and verbs for functional abstractions. Module names should be without spaces, in mixed case, with the first letter uppercase, and the first letter of each subsequent word capitalized. The file name of the module should match the internal name of the module
Rationale: Consistency with standard Visual Basic naming conventions. Ease of deployment.
Examples:
Show Matches.firm
Registry.bas
Send Msg.bas
Customer.cls

PROCEDURE NAMES

GENERAL PROCEDURE NAMES

S) Procedure names should be meaningful verbs or verb phrases that describe the functional abstraction of the procedure. The first word should be a verb. Procedure names should be without spaces, in mixed case, with the first letter uppercase, and the first letter of each subsequent word capitalized.
Rationale: Consistency with standard Visual Basic naming conventions. Encourages names which allow the reader to visualize the purpose of the procedure
Example: Open Data File

BOOLEAN FUNCTION NAMES

S) Functions that return the results of a test of a Boolean condition T should be named IsT, HasT, or CanT.
Rationale: Consistency with standard Visual Basic naming conventions. Encourages readable code when the function is used in a condition.
Examples:
Connection.Is Available()
Router.Has Pending Request()
If Is Broken() Then Exit Sub

CONVERSION METHOD NAMES

S) Name methods that convert an object to a particular format F ToF.
Rationale: Consistency with standard Visual Basic naming conventions.
Example: to String

STATE MODIFYING METHOD NAMES

S) Name methods that modify the state of an object to state S BeS.
Rationale: Consistent naming.
Examples:
Be Available()
Be Unavailable()

VARIABLE AND PARAMETER NAMES

Variable and parameter names should be meaningful noun or noun phrases, without spaces, with the first letter lowercase and the first letter of any subsequent words capitalized. The first few letters of the variable name define the type of the variable. The remainder of the name should describes the role that the variable plays.

ATOMIC TYPES

S) For atomic types, the first letter of the name defines the type, as follows:
Prefix
Types
Example
i
Integer or Long
i Word Count
f
Float (Single or Double)
f Radius
s
String
s First Name
b
Boolean
b Quiet
c
Currency
cCurrentBal

d
Date
dStartTime
Rationale: Consistency with standard Visual Basic and Windows API naming conventions. Allows easy identification of the type and role of a variable, without adding a lot of naming overhead for frequently used types.

OBJECT AND COMPLEX TYPES

COMBO BOX
EcoleBooks | COMPUTER FORM  6 - VISUAL PROGRAMMING
This is a scrow box which is used for top/ down scrowing and right/left scrowing.
CHECK BOX
This is the box which allow you to select what you need
EcoleBooks | COMPUTER FORM  6 - VISUAL PROGRAMMING
TEXT BOX / LABEL

EcoleBooks | COMPUTER FORM  6 - VISUAL PROGRAMMING
Text box allow user to write a text inside it and you can delete it.
Label is a place where developer is write a text he/ she need to appear at the form.
Command Button
Command Button is one which is used to send data to the database when user click it
Command button respond when user click on it
EcoleBooks | COMPUTER FORM  6 - VISUAL PROGRAMMING
FORM WITH VISUAL BASIC

EcoleBooks | COMPUTER FORM  6 - VISUAL PROGRAMMING

S) For objects and complex types, and three-letter prefix defines the type, as follows:
Prefix
Type
Example
frm
Form
frm Crustiness
txt
Text Box
text Last Name
lst
List Box
lstServiceTypes
cmd
Command Button
cmd Cancel
cbo
ComboBox
cbo Category
pic
PictureBox
pic Logo
chk
CheckBox
check Primary Address
opt
Option Button
opt GenderFemale
tmr
Timer
timer Elapsed
lbl
Label
lbl copyright
tbr
Toolbar
tbr Editing
ctl
Control (if type is not known)
ctl Sortable List
col

Collection
col Form Fields
obj
Object (if type is not known)
obj Parent
var
Variant (if type is not known)
var Next Field
Many other types are possible which are not on this list, including user-defined types and objects. For these types, and appropriate three- or four-letter prefix convention should be established and documented for the project.
(Note that the frm prefix should be used only for a variable in the code which holds a form reference, and not the VB class and file which defines the form. Form modules should be named as per the section “Module Names”, above.)
Rationale: Consistency with standard Visual Basic and Windows API naming conventions. Allows easy identification of the type and role of a variable.

CONSTANT NAMES

S) The names of constants should be meaningful noun or noun phrases with all letters capitalized and underscores between words.
Rationale: Consistency with standard Visual Basic and Windows API naming conventions. This convention emphasizes and differentiates constants from variables.
Example: MAXIMUM_NUMBER_OF_FILES

ARRAY NAMES

S) Array names should begin with a lower case “a”, followed by the prefix which describes the type of the array members, as described above, and followed finally by the descriptive name of the variable.
Note that Variants must often be used to hold arrays when they are passed as return values from functions. In this case, the Variant should be named according to the array naming convention.
Rationale: This identifies the variable as an array, and indicates its contents as well.
Example:
Dim as User Names(10) As String
Dim afVertices() As Single
Dim as Words As Variant
as Words = Split(sLine, vb Tab)

GLOBAL VARIABLE NAMES:

S) Names for global variables should follow the above conventions, but with a “g_” prefix before the name. Likewise, private module-level variables should have a “m_” before the name.
Rationale: This eases identification of global and module-level variables. While this convention is somewhat cumbersome, it appropriately discourages use of global and module-level variables.
Example:
Public g_sCurrentUser As String
Private m_aiTroubleCodes As Integer

MISCELLANEOUS

S) Do not use abbreviations or acronyms unless they are extremely popular abbreviations in the project. The prefix standards described above or established by the project are examples of popular abbreviations, which are exempted.
Rationale: Abbreviations and acronyms make the code harder to understand.
Example:
sOutstandingBalance instead of sCurOutBal
S) Document cases where the client ignores the return value.
Rationale: This is typically an error; if not, make the intent clear.
S) Use plural for collections and singular for individual objects.
Rationale: This makes the names easier to understand.
Examples:
Dim colOpenForms As Collection

Dim asApprovedNames() As String




Share this:


EcoleBooks | COMPUTER FORM  6 - VISUAL PROGRAMMING

subscriber

Leave a Reply

Your email address will not be published. Required fields are marked *

Accept Our Privacy Terms.*