MIS3362:  Guidelines for VB programs

Adhere to MS Style conventions and recommended naming conventions.

Naming conventions:

Objects

Projects--one word short descriptive name.  See book for details about avoiding spaces, special characters, etc.

See your book for details

Variables (Make as local as possible)

See your book for details

Assign the contents of textboxes and other controls to variables and use variables in computations.  This makes formulas shorter, easier to understand, and easier to debug.  It also helps to assure that data is in the proper form for use in computations (numbers and not texts).

**     Place an m in front of prefix for all form level variables.
***   According to the book, good programming practices preclude the use of namespace variables (formerly called global variables).

Constants (Make as local as possible as with variables)

Constants:  All constant declarations start with Const and use an appropriate variable type prefix and ALL CAPS for the rest of the name.  Proper naming of single precision floating point constant is demonstrated below as it would be declared in an appropriate procedure.  Note the constant is assigned a value in its declaration.

       Const DUMMYSingle as Single = .475F

It is generally wise to use constants for values that are used in your program, but will not change during execution.  If they will not be used in more than one place in the program, and it is not likely to require change during the life of the application, I often just use the number itself (magic number as we called it years ago).

Type-declaration characters (after value assigned) are as follows:

    Decimal    D
    Double     R
    Integer      I
    Long         L
    Short        S
    Single       F

User Defined Data Types

Use naming conventions recommended by your book--udt as the prefix for your user defined data type objects, unless many are used, then precede with names like uco for Customer, or uiv for inventory.  I recommend that you create your UDTs in a separate module, thus making them more easily available to other projects you might create.

Access Keys:

Create appropriate access keys for controls that execute code and/or require input or user action.  To include:   

DO NOT DUPLICATE an access key on a form as it will be a source of confusion. Exception: buttons and menu choices that execute same code. 

Be mindful of the NORMAL/ACCEPTED use of access keys, such as "x" for Exit, "s" for Save, "F" for File and so on. 

Tab Order and Focus:

Always set your tab order to reflect most likely sequence of user actions.  Set focus appropriately to facilitate efficient use of the VB application.  Properly setting the tab order and the focus require a good understanding of user needs.  THINK!

Default and Cancel:

Generally a button/menu choice should be selected as the default (executed on enter--accept button property) and you should select an appropriate action to be executed on ESC (set cancel property of some control to true).

Organization of Objects on User Interface:

Forms and objects should be organized in a manner that reflects the most likely sequence of user actions.  For example, your command buttons should be arranged in the order in which they would most likely be used (Left to Right for horizontal organization and Top to Bottom for vertical organization).  Use the SetFocus to transfer focus among controls in an appropriate manner.  For instance, when doing data entry, you might have text boxes for data and a "Save" button to save each record as typed by the user.  The Save button could transfer the focus to the text box each time it is selected--so the user need not do so him/her self.

General Guidelines on Form Organization:

Center forms on screen at startup.

Forms should have little wasted space thereon.  Space between objects should be approximately two dots on the design grid which is about 240 twips, I think.  For example:     | . .Start Object about here!  

All margins around form (from objects to edge of form should be approximately two dots or 240 twips).  Minimize margins on the form.  That means that controls should be aligned horizontally and vertically to the extent that there are few margins to be lined up.

Colors should be for the most part grays and whites. 

Fonts should be black and standard size, unless it is really important to use a larger size and color for emphasis.  San Serif (without feet) fonts are best for forms (viewed on screen) and Serif fonts are best for printed materials (for reports and such).

Text boxes should be white, and labels that are used for output should be transparent, flat, and and have a thin border around them.

Groupboxes provide a convenient way of creating logical groups of controls (putting things together that go together).  Use captions on your groupboxes if it is important to name the contents (often it is), otherwise leave them off.

It is generally a good practice to center your form on the user's screen. 

Horizontal lines can likewise be used to separate sections of a form, but use them sparingly.  It looks tacky when you get carried away in using them.

In Program Documentation:
In General Declarations Module (Form--General)

'Project:          Chapter 2 Practice
'Date:              January 22, 2003  (should be due date)
'Programmer:  Dr. Mc
'Description:   The purpose of the program is to demonstrate
'                      various concepts for the class. The program
'                      solicits information about a student's grades
'                      and major and uses that information to
'                      forecast his/her potential earnings. A graph
'                      shows the results and the form is printable.
'Folder:           Ch2_Practice  NOTE: Folder name is project name--automatic if done correctly.

Each procedure should have a short description of its purpose and sufficient in-code documentation to allow one to understand what it is doing--a non programmer should be able to read the in-code documentation and understand, generally, what is going on.

Design Documentation:

The Picture of User Interface should be neat, reflect actual size and organization of the user interface, and should be a picture of what you actually intend to build (consistent in every respect with the form you actually build). Professional quality required--do it on a computer or use a ruler and/or design template to make it so.

The Object Plan should describe you plans to change object properties either at design time, or at run time.  It should look like the one in your book (except for using single space within object properties and DS or solid line between objects) and it should be neat.  If you are going to change a property of an object at design time, include it in the Object plan.  Professional quality required--do it on a computer.

The Pseudo Code should describe ALL programming to be done.  Any action that is to be executed in code must be described herein in such a way that a programmer could read it and get a clear understanding of the coding to be done.  See examples in your book and on the Website (The News Page right under Word for the Day and Quote).  Professional quality required--do it on a computer.

The Variable Plan.  See Variable Plan Format  New! for variable plan.

Disk Organization:  (DO IT LIKE THIS!)

Place every Programming Exercise and Case study in a folder by itself (The folder is created for you if you name it properly when you start a new project/solution), and place them in a chapter folder.  For example, if you hand in an exercise and a case study for chapter two, name the main folder Chapter2 (no spaces).  Create and name the Exercise 1.3 folder Ch2_EX_1_3 by properly naming the solution.  For the Chapter 2 Case study (you are doing same one throughout book) create a solution and name it Ch2_VB (stands for Video Bonanza, or whatever Case study you are doing).  Use this naming scheme for all of your work in here and it will not be difficult for me to find them on your disk!

When I (or you) think of anything I may have left off, I will add it.  Most recent changes appear in red.

Created on 1/24/2003
Last changed on 8/18/2008 @ 2:30 p.m.