Articles

Overview

Good coding standards are important in any development project, but particularly when multiple developers are working on the same project. Having standards helps ensure that the code is of a high quality, has fewer bugs, and is easily maintained.

These standards are based on years of developing Visual FoxPro applications and learning what coding techniques work best. Also, many concepts from Code Complete (Microsoft Press, ISBN 1-55615-484-4) by Steve McConnell have been adapted. This book is considered one of the premier guides on coding practices. You may not agree with these standards, and that's ok. These have worked well for me.

Coding Standards

Variable Usage

Do not use underscores in variable names. Mixed case should be used to improve readability. The first letter of the variable name should indicate its scope and should always be lower case. Try to avoid the use of global (PUBLIC) and private variables. Instead, use application object properties, form properties, and local variables.

l Local

g Global

p Private

t Parameter

The second letter indicates the data type

c Character

n Numeric

d Date

t DateTime

l Logical

m Memo

a Array

o Object

x Indeterminate

Examples of valid variable names:

lcFirstName
tdBeginDate

Keep variable scoping in mind. LOCAL variables should be used as much as possible. PUBLIC variables should be avoided if at all possible. Variable declarations such as LOCAL lcMyVar should be placed at the beginning of a routine rather than spread throughout the routine. Declare all variables at the beginning of the routine rather than interspersed throughout the code and have a default value assigned to it.

Wrong way:

LOCAL lnMyNum
lnMyNum = 12

LOCAL lcMyString
lcMyString = "ABCD"

LOCAL lnCounter
lnCounter = 0

Object Naming Standards

The first three letters of an object name should be used to indicate the type of object.

chk Check box

cbo Combo box

cmd Command button

cmg Command Group

cnt Container

ctl Control

cus Custom

edt Edit box

frm Form

frs Form set

grd Grid

grc Grid Column

grh Grid Column Header

img Image

lbl Label

lin Line

lst List box

olb OLE Bound Control

ole OLE Object such as an ActiveX Control

opg Option Group

pag Page

pgf Pageframe

sep Separator

shp Shape

spn Spinner

txt Text box

tmr Timer

tbr Toolbar

Source Code Standards

Use white space liberally. It will improve readability.
Use tabs instead of spaces for indenting.
FoxPro commands and functions should be capitalized and spelled out completely. Everything else should be in mixed case. When possible, keep lines short to avoid line wrap when printed. If a line needs to be continued put “join” statements as the first character of the next line. Join statements are things like +, AND, OR, NOT, etc. Also remember that the line must be valid as if all on one line. Put a space before the semi-colon.

Examples of bad continuations:

lcCommand = "Today is Wednesday, October 16, 2003" + ;
"The time is 2:00 PM"

IF ldBeginDate >= DATE() OR ;
ldEndDate >= DATE()

Examples of good continuations:

lcCommand = "Today is Wednesday, October 16, 2003" ;
+ "The time is 2:00 PM"

IF ldBeginDate >= DATE() ;
OR ldEndDate >= DATE()

It seems that everyone does case statements differently. While there is no right or wrong way, some seem to help readability. Also, use a CASE statement instead of an IF when it appears that more options could be added at a later date, even if there are only two options at the time the code is written, or to get rid of IF, ELSE, IF constructs. Separate each CASE with a blank line. The comment for the CASE should go underneath it.

Wrong way:

DO CASE
* This is the comment for case 1
CASE lnCount = 1
lcRetVal = "One"
* This is the comment for case 2
CASE lnCount = 2
lcRetVal = "Two"
* This is the comment for otherwise
OTHERWISE
lcRetVal = "Another"
ENDCASE

Correct way:

DO CASE
   CASE lnCount = 1
      * This is the comment for case 1
      lcRetVal = "One"

   CASE lnCount = 2
      * This is the comment for case 2
      lcRetVal = "Two"

   OTHERWISE
     * This is the comment for otherwise
     lcRetVal = "Another"
ENDCASE

Try to avoid macro substitution. There are times when macro substitution is the only way to accomplish something. Make sure that you document why you used macro substitution and what the purpose of the code is. In most cases, macro substitution makes the code less readable. If possible use the EVALUATE() function, but again, good comments are important to aid in code readability.
Avoid use of STORE.
Use “[ ]” instead of parenthesis for arrays. It improves readability.
Put spaces around math operators. This improves readability.
Use parenthesis when calling methods or functions, even if no parameters are passed.
Avoid the use of m. on the left side of an equal sign. It will improve performance.
When doing a string concatenation, put the variable on the left side of the + sign. It will improve perfomance.

Commenting Standards

Comments are an important part of any application. Use them liberally. Comments should explain why something is being done and indicate what lines of code are affected. You should only explain how something is done if it is using complex algorithms or calculations.

Do not use comments at the end of a line with &&. Each comment should be on a line by itself.

Program, Method and Procedure Headers

Program, method and procedure headers should indicate the name of the routine the date it was originally created, the author, and a description of the procedure or method’s purpose. Include a description of parameters and return values, if any. For methods, include the object hierarchy.

Commenting Modifications

It is important when making modifications to know what modifications were made, and why you made them. The Modification Summary section in the header should explain the why of a modification, when it was made, and who made it. At each place in the code where the modification was made, you should comment out the old code and indicate what new code was added. Each modification should be numbered. Changed code can be removed after one year, but the summary comments in the header should always remain.

User Interface Standards

General UI Standards

When possible, the user interface should comply with the Windows Standards guidelines as described in the book “Microsoft Windows User Experience”, Microsoft Press, ISBN 0-7356-0566-1. This book is also available online at http://msdn.microsoft.com/library/en-us/dnwue/html/welcome.asp. Always keep the user in mind. The easier the function can be for the user, the better the application. This may mean that the code behind the function is more complex.

KB015: Visual FoxPro Coding Standards

Topic: Visual FoxPro

Last updated: September 26, 2003