programming standards guide

8/6/2019 Programming Standards Guide

1/30

Programming Standards 1999 PDS ConfidentialRnS.dot Version 1.3

Programming

Standards andConventions

Guide


2/30

March 2, 1999 Programming Standards and Conventions Guide Page 2


Introduction

The purpose of this document is to promote a few common practices and

standards to make systems more robust, have fewer errors and be more

maintainable. These conventions and standards are meant to encourage thedevelopment of a common understanding of how a piece of software should

be written and to set minimum expectations of the developers.

These standards are intended to facilitate the exchange of ideas and to assist

developers in understanding others work. They are also intended to reduce

the learning curve of developers who are new to the team.

This document is to serve two purposes. The primary purpose is to provide a

record of the conventions and standards that were used on a specific project.

To this end, the version of this document that was relevant at the time a

project was completed should by included in the permanent record of the

project so that developers maintaining the project can understand thestandards and conventions in use for that project.

The secondary purpose is to provide a repository for the current thinking on

how a project should be developed. No set of standards is ever complete or

final. Rather standards evolve as time goes by as techniques are refined and

as new ideas are tested and adopted or discarded. No standard in this

document is sacred and cannot be improved upon or replaced at some pointin the future. However, they do represent the concerted effort on the part of

the development team to establish an understanding of how work is to be

done and as such they must be either conformed to or changed by agreement

of the team.

Programmers found to be repeatedly in violation of these standards and

conventions will be ostracized, ridiculed, exiled and finally, sacked.

Note: The terms program and code in this document can be taken to

mean any file or other piece that makes the source for the

executable program or the data on which that program operates.


3/30



Development EnvironmentConventions

Whenever a program is written, the configuration of the workstation that

created the program may be a determinant in the successful execution and

maintenance of the program. The program may not run properly or be able

to modified on a workstation with a different configuration. In order to avoid

these types of problems all workstations must either be restricted to a

minimum configuration or a standard configuration must be agreed upon.

Directory Structures

In lieu of storing all files in a single directory, an organized structure needs to

be established so that there is no confusion over where a particular piece ofcode belongs or over how to find a piece of code. While there are an infinite

number of ways to organize files into directories, in general, the organization

should be on a functional basis.

The following figure shows a sample development directory structure for

storing source code.


4/30



At the highest level is the enterprise and/or client for whom the work is being

performed, in this case rns. Under the enterprise are the major units of work.Here we have, gears, ibps, leader, leaderCounts, leaderDetail, legacy,

newR&S and schemas. There is a special unit for code that is common to all

units.

Each unit except for the common unit, may contain any or all of the

following three sub-units: meta, load and prod. Meta is used for storing themetadata for the unit. This is the information about the data not the actual

data. Load is used for building the production schema from the metadata and

populating the production schema from external sources. Prod is the actual

data.

Within each sub-unit and the common unit are subdirectories for the actualsources files. For example, classes, reports, prgs, images and forms. The

number of these directories and their names can vary from sub-unit to sub-

unit.

In addition to the source code directory structure there are two other

directory structures, the following is an example of one of these structures:


5/30



This structure is the data directory. The data directory contains all data for

every unit and sub-unit in the enterprise. In this case the directory rnsData,

contains a subdirectory for gears which has subdirectories for load, meta-dataand production. These directories contain the database and tables for their

specific sub-units. For the meta sub-unit, this would contain the meta-data,

or data about the data, in the load sub-unit, it would contain any persistent

data required to assist in the loading of the external data, in a prod sub-unit,

the data directory would contain the actual production data.

The other directory is the inbox directory. The following is an example of an

inbox directory tree:

The inbox directory is for storing external sources of data that are processedby the sub-unit. In this case the inbox directory is rnsInbox. Like the data

directory, the units with the inbox directory are seperated into sub-units. In

the meta sub-unit this could be documents or tables containing meta-data that

is used to build the meta-database. There can be subdirectories to organizethe external data by set and by type. The load directory would contain flat

files or extracts containing production data from other systems that is to be

loaded into the production database for the unit. Typically there is no

production inbox sub-unit directory.


6/30



Default Directories and Paths

In general programs should be written so that they function without having to

depend on the setting of the current directory. If a program needs to create a

new file, the path to the new file should be explicit and should never be

created in the default directory. If for some reason a routine needs to changethe current directory the current directory should be restored before the

completion of the routine.

In order for files to be easily found and executed while developing without

having to explicitly specify a directory, a path can be established to the

various directories containing the needed files. These paths may depend on a

specific default directory requiring the developer to change to the directory in

order for the path to function properly. It is important to note that the

development environment is dependent on the setting of the default directory

and not the executing code.

Whenever a path is used, a relative paths should be used whenever possible.Paths are not to be hard coded into programs. In code, the default path

should be set in a header file and then allowed to be changed by the user

during the execution of the code. Use the VFP path only to locate files in

development.

In development the following or similar path should be used:

set path to ;d:\work;classes;forms;prgs;reports;sql;..\;..\..\;..\..\common\classes

This path depends on setting the directory to a sub-unit. Relative paths then

allow all the files in the sub-unit as well as the root directory of the unit and

enterprise to be accessed without having to specify a directory when referring

to a file. In addition, absolute paths are used to directories containing filesthat are common to all units as well as to the developers own local work

directory.

This path breaks down as follows:


7/30



Path Description

d:\work Local work directory

Classes Relative path to the sub-units classes directory

Forms Relative path to the sub-units forms directory

Prgs Relative path to the sub-units programs directory

Reports Relative path to the sub-units reports directory

Sql Relative path to the sub-units sql directory

..\ Relative path to the sub-units unit directory

..\..\ Relative path to the enterprise directory

..\..\common\classes Relative path to the common classes directory

Temporary Files

In order to reduce the clutter created by temporary tables, test programs and

other types of work in progress, all files that are not a permanent part of the

project should be stored in a local directory and not within the enterprise

directory structures. The reason for this is that it can be very difficult todelete files in a public or shared directory for fear of deleting a file of import

by accident. This results in the bloating of directories with files that are no

longer of use.

The developer should take care whenever a new file is created in a shared

directory to ensure that the new file is indeed a relevant and permanent partthe project. In addition and more importantly, developers need to make sure

that they remove files from the shared directories whenever files become

obsolete and are no longer relevant or needed.

Archives

The shared directories are not to be used to store archives of data files or

code. The shared directories should only contain the current state of the

work in progress.


8/30



Configuration

Required Options dialog configurationsettings

The following VFP configuration settings are required

Tab Option Setting

General Year 2000 Compliance Contstants plus CTOD() and CTOT()

dBase Compatability Off

Data Open Exclusive Off

Prompt for code page Off Remote Data Share Connection On

Show Login Never

Idle Timeout 10

File Locations Builders j:\dev\builder.prg

Forms Maximum design area 800x600

Builder Lock On

Project Active source code control provider None

Regional Use System Settings On

Suggested Options dialogconfiguration settings

The following options are optional but suggested.


9/30



Tab Option Setting

Data Automatic file locking On

Multipule record locks On

Buffering Record (optimistic)

File Locations Startup Program c:\work\foxstart.prg (Example in

j:\dev\rns\common\prgs)

Forms Show Position On

Form WizardForm

(j:\dev\rns\common\classes\rnswizard.vcx)

Prompt to save changes before

running form

Off

Controls Selected Rnswizard

Label Wizards

Syntax Coloring Comments Green, BoldKeywords Blue

Literals Red

Operators Dark Grey

Strings Light Purple

Variables Dark Blue

Required configuration file settings.

Every developer should use a configuration file to configure settings that

cannot be set in the Options dialog. An example configuration file is located

in thej:\dev\rns\common\fpwdirectory.

The configuration file can be invoked by using the c command line option

for VFP. One way to do this is to create a shortcut to the VFP executable

and change the target property to something similar to:

"C:\Program Files\VS\Vfp98\VFP6.EXE" -cc:\work\rns.fpw
http://r_and_s/VOL1/FOXPRO/dev/rns/common/fpw/rns.fpwhttp://r_and_s/VOL1/FOXPRO/dev/rns/common/fpw/rns.fpwhttp://r_and_s/VOL1/FOXPRO/dev/rns/common/fpw/rns.fpw


10/30



Programming Conventions

Header Files & ConstantsPredefined constants should be used to define literal values in an application.

The constants should be defined either in the program in which they are

referenced or preferably, in any of the following header files if the constant is

needed by more than one routine.

The Local Header File

Every workstation must have a local.h file in root directory of the c: drive.

The purpose of this file is to allow the definition of constants that are

workstation or user specific. This file should contain at least the followingstatements:

#define localHloaded "Yes"

#define ENTERPRISEPATH pathtoenterprisedirectory

#define ENTERPRISEDATAPATH pathtoenterprisedatadirectory

#define ENTERPRISEINBOXPATH pathtoenterpriseinboxdirectory

The localHloaded constant is used to verify that the header file is beingloaded when a program is compiled.

The ENTERPRISEPATH constant defines path where this workstation finds theenterprise source files. The valuepathtoenterprisedirectory is the path to the

root directory of the enterprise source.

The ENTERPRISEDATAPATH constant defines path where this workstation finds

the enterprise data files. The valuepathtoenterprisedatadirectory is the path

to the root directory of the enterprise data.

The ENTERPRISEINBOXPATH constant defines path where this workstation finds

the enterprise inbox files. The valuepathtoenterpriseinboxdirectory is the

path to the root directory of the enterprise inbox.

The Enterprise Header File

The Enterprise header file contains constants that are common to all units

within the enterprise. The enterprise header file is located in the enterprise

root directory. The most important use of the enterprise header file is to

define the locations of all the units and sub-units. The following is a portion

of an enterprise header file.

#include foxpro.h


11/30



#include c:\local.h

#define EnterpriseHLoaded "Yes"

#define CRLF chr( 13 ) + chr( 10 )

#define TRUE .t.

#define FALSE .f.

#define PEMSTATUSUSERDEFINED 4

#define PEMSTATUSDEFINED 5

#define ZORDERTOBACK 1

#define RNSWIZARDVCX 'j:\dev\rns\project\classes\rnswizard.vcx'

#define RNSLOGPATH 'j:\dev\rnsdata\logs\'

#define DEVDEPLOYMENTMODE 'DEV'

#define TESTDEPLOYMENTMODE 'TEST'

#define PRODDEPLOYMENTMODE 'PROD'

* Change this definition to one of the above definitions and

recompile all files

#define DEPLOYMENTMODE DEVDEPLOYMENTMODE

#if DEPLOYMENTMODE = DEVDEPLOYMENTMODE

#define DEBUGLOG \D:

#define EXECUTIONLOG \E:

#elif DEPLOYMENTMODE = TESTDEPLOYMENTMODE

#define DEBUGLOG \D:


#else

#define DEBUGLOG *


#endif

* ----------------------------------------------------------- *

* Default paths to sub-units


12/30



* >---------------------------------------------------------- *

#define LOADPATH "load\"

#define METAPATH "meta\"

#define PRODPATH "prod\"

* ---------------------------------------------------------- *

* Unit path

#define GEARSPATH ENTERPRISEPATH + "gears\"

#define GEARSDATAPATH ENTERPRISEDATAPATH + "gears\"

#define GEARSINBOXPATH ENTERPRISEINBOXPATH + "gears\"

* Sub-unit paths

#define GEARSLOADPATH GEARSPATH + LOADPATH

#define GEARSMETAPATH GEARSPATH + METAPATH

#define GEARSPRODPATH GEARSPATH + PRODPATH

* Load sub-unit working directories

#define GEARSLOADDATAPATH GEARSDATAPATH + LOADPATH

#define GEARSLOADINBOXPATH GEARSINBOXPATH + LOADPATH

* Meta sub-unit working directories

#define GEARSMETADATAPATH GEARSDATAPATH + METAPATH

#define GEARSMETAINBOXPATH GEARSINBOXPATH + METAPATH

* Prod sub-unit working directories

#define GEARSPRODDATAPATH GEARSDATAPATH + PRODPATH

#define GEARSPRODINBOXPATH GEARSINBOXPATH + PRODPATH

* DBC file names

#define GEARSLOADDBCNAME 'GearsLoad'

#define GEARSMETADBCNAME 'GearsMeta'

#define GEARSPRODDBCNAME 'GearsProd'


13/30



* DBC file specifications

#define GEARSLOADDBC GEARSLOADDATAPATH + GEARSLOADDBCNAME

#define GEARSMETADBC GEARSMETADATAPATH + GEARSMETADBCNAME

#define GEARSPRODDBC GEARSPRODDATAPATH + GEARSPRODDBCNAME

* Project file specifications

#define GEARSLOADPROJ GEARSLOADPATH + 'GearsLoad'

#define GEARSMETAPROJ GEARSMETAPATH + 'GearsMeta'

#define GEARSPRODPROJ GEARSPRODPATH + 'GearsProd'

*


14/30



The sub-unit header file must include the unit header file so that the unit,

enterprise and local constants are defined.

Every program, form or class in a sub-unit must include that sub-units

header file.

Including header files in code

The header file structure depends on a couple of settings to function properly.

What file to include?

Depending on the location of the code, one of two files should be included in

any code that references any constant.

If the code is part of a common component and not part of any unit or sub-

unit component then the enterprise.h file should be included. This implies,

correctly, that common components cannot reference constants defined inany unit or sub-unit.

If the code is part of a unit or sub-unit component then the #include shouldreference the unit.h or subunit.h file.

Paths

This header file scheme uses nested #include statements to incorporate the

other include files. The subunit.h file includes the unit.h file, which in turn,includes the enterprise.h file, which then, includes the local.h file and

foxpro.h file. Since the #include statements do not specify the path to theheader files explicitly, the VFP path is used to locate the included files.

Default directory

Since the header files for each unit have the same names, as do the header

files for each sub-unit, it is imperative that the default directory be set

correctly before compiling any code. Otherwise, the wrong header file could

be used or the included file might not be found.

Naming Conventions

Memory Variables and Constants

Follow this format for naming memory variables:


15/30



Syntax: [Scope]TypeName

Arguments: Scope A convention for noting the range of reference for

the variable. For example, local variables are

prefixed with l, which reminds you that they can

referenced only within the procedure in which they

were defined.

Expressions for Scope are as follows:

Scope Description Example

l Local lnCounter

g Public (global) gnOldRecno

t Parameter tnRecNo

v View Parameter vnId

r Report Variable rcName

Note: The private scope declaration should not be used and all

variables not explicitly declared as global that are not report

variables or view parameters should be explicitly declared as

local.

Type Convention for noting the data type of a variable.

Prefixes for Type, which are taken from the return value of the vartype

function, are as follows:


16/30



Type Description Example

a Array laMonths Use brackets instead of parentheses. Goal is to

avoid confusion between function/method calls

and arrays, since methods/functions never start

with [, there should be no confusion.

c Character,Memo

lcLastName

y Currency lyCurrentValue

d Date tdBirthDay

t Datetime vtLastModified

l Logical rlFlag

n Numeric,

Double,

Integer,

Float

lnCounter

o Object poEmployee poFrmMyForm = CreateObject(MyForm)

u Unknown luReturnValue

Note: Using a prefix does not dictate the value of a variable in

Visual FoxPro, prefixes are used as a naming convention. For

example, adding the prefix c does not check that only

character data is stored to the variable, but it does help you

remember that the variable was created to accept character data

In some cases, explicit scoping does not apply. For example, in

the main program of a stand-alone application, there is no

difference in visibility for variables scoped as PUBLIC or

PRIVATE. The type prefix is always relevant and is required in

sample programs.

Objects

Controls/Containers

Follow this format for naming objects:

Syntax: PrefixName

Prefixes for object names are as follows:


17/30




18/30



Prefix Object Example

Cbo ComboBox cboZipCode

Chk CheckBox chkReadOnly

cmd CommandButton cmdCancel, cmdOk

cmg CommandGroup cmgChoices

cnt Container cntMoverList

ctl Control ctlFileList

cur Cursor curCurrentView

cus Custom cusCustom

dev Data Environment devDataEnvironment

edt EditBox edtTextArea

frm Form frmFileOpen

frs FormSet frsDataEntry

gra Graph/Chart graExpenseCategories

grd Grid grdPrices

grc (Grid) Column grcCurrentPrice

grh (Grid) Header grhTotalInventory

img Image imgIcon

lbl Label lblHelpMessage

lin Line linVertical

lst ListBox lstPolicyCodes

ocx OLE unbound control ocxTreeView

olb OLEBoundControl olbObject1

ole OLE oleObject1

opt Option Button (Radio Button) optFrench

opg OptionGroup opgType

pag Page pagDataUpdate

pgf PageFrame pgfLeft

rel Relation relCurrentRelation

sep Separator sepToolSection1

shp Shape (circle, square, oval, rectangle, rounded

rectangle, rounded square)

shpCircle

spn Spinner spnValues

txt TextBox txtGetText

tmr Timer tmrAlarm

Tbr ToolBar tbrEditReport


19/30



Note: Using a prefix does not dictate the contents of an object variable

in Visual FoxPro, prefixes are used as a naming convention. For

example, adding the prefix cbo does not check that the object

referenced by the variable is a combo box, but it does help you

remember the object referenced by the variable.

Field Names

Follow this convention for naming fields in tables:

Surrogate primary keys are namedId

Prefix any foreign key fields with the foreign key table name followed byId e.g., actId

Coding Conventions

Abbreviations

Do not abbreviate keywords (even if the language allows you to

abbreviate) in code.

White space

Use horizontal white space (i.e., spaces) between operators, operands, etc. to

separate the components of commands and expressions.

Use vertical white space (i.e., blank lines) to separate groups of statements

and delineate sections of code. Use the following rules:

All code blocks within a loop or a branch consisting of more than a single

line must begin and end with a blank line. Follow the end of a loop or a

branch with two blank lines. Separate dissimilar statements with a blank

line.

For example:

do while len( lcLine ) > 0

lnSpace = at( ' ' , lcLine )

if lnSpace > 0

lcWord = left( lcLine , lnSpace - 1 )


20/30



else

lcWord = allt( lcLine )

endif

lcLine = allt( subs( lcLine , len( lcWord ) + 1 ) )

lnWordCnt = lnWordCnt + 1

if alen( laWords , 1 ) < lnWordCnt

declare laWords[ lnWordCnt ]

endif

laWords[ lnWordCnt ] = lcWord

enddo

When to use Capital Letters (all UPPERCASE)

Use Capital letters (all UPPERCASE) for the

following:

Example

Constants MAX_VALUE

When to use lower case

Use all lower case for the following: Example

Commands set help to

File Names buttons.vcx

Keywords order

Paths (with separating backslashes) c:\windows

When to use Mixed Case


21/30



Use Initial letters (ProperCase) for the following: Example

Events getFocus

Methods writeExpression

Objects oEmployee

Properties allowRowSizing

Procedures getNextId

Note: The initial character should always be in lowercase and if the

name consists of more than one word, the initial-capital words

are concatenated.

Copyright

Every piece of code created or updated should contain the copyright of theperson who created the code with the understanding that you are granting an

unrestricted license to the client to use the code for the purpose it was

written. This should include the date and time the code was created or

modified, the name of the person who did the work and the company they

were affiliated with at the time the work was done. For example:

Copyright Feb 24, 1999 John M. Miller, Perpetual Data Systems

The following statement can be modified to insert a copyright when a key is

pressed:

on key label f10 keyboard "* " + transform( datetime() ) + " jMM"

The purpose of this is to document in the code, the persons responsible forthe code as it exists. If your name is associated with a piece of code,

hopefully youll take more care in writing it.

If for some reason a piece of code is completely rewritten the previous

copyrights can be removed.

Comments

While the importance of properly documenting work cannot be over

emphasized, it is important to properly comment code in order to get the

expected benefits. First of all, realize that a comment is no different than any

other programming statement. Once it is created, it has to be maintained and

since a comment is not a functional part of the code, it is the last thing to be

changed, if changed at all. Comments are not inherently good and if

incorrect can be detrimental.

When the time comes to document your code try to answer the following

questions:


22/30



What does the code do?

In general, nothing documents what code does better than the code itself.

Therefore, be careful when adding comments that describe what the code

does. These types of comments can be helpful when the code is difficult to

read or understand. But if the code is difficult to read or understand you

should also think about the possibility that it should be rewritten in a clearermore readable way.

Also, these types of comments are subject to becoming obsolete quickly as

the code changes with time.

Why was the code written?

This is probably the most useful type of comment. Every piece of code has a

purpose and every piece of code should have a comment that explains that

purpose. Sometimes the purpose is due to a business need, in other times the

purpose is purely technical.

Typically, the purpose of a routine is constant no matter how many different

ways are used to implement the purpose. This makes these types of

comments much more stable.

If a routine has multiple purposes it is a good candidate for splitting into

separate routines.

How does the code work?

This is similar but slightly different and more useful than the What type of

comment. In this type you are trying explain in a general sense how the code

meets the purpose of the routine. These types of comment only need tochange when a different approach to implementation is tried.

Program Logs

Every program, form or report should log its execution to a log file located in

the Logs directory. The log should contain any and all information necessary

to determine whether the program executed properly.

Assertions

All situations where an error could occur as the result of a programmer errorshould be asserted in the code using the VFP ASSERT command and the

code should be tested with ASSERTS set ON to trap for these conditions.


23/30



Runtime Errors

For situations where errors occur at runtime that cannot be avoided the code

should trap for the specific error using the VFP error handling features.

Preferably this would be done using the error method of an object.

VFP Errors

An application level error handler should be used to trap all errors and

respond to the error according to its type and severity. This would typically

be implemented using the VFP ON ERROR command.

Application Errors

The are situations where a routine reaches a point where it cannot continue

and must abort processing. In these situations the routine should generate a

user defined error condition. Then test for continued existence of the

condition before aborting. This allows a subclasses error method or an error

handler to trap the error and resolve the error condition without changing thecode.


24/30



Source code control

Some form of source code control system must be used on all projects.

There are three reasons for using a source code control system:

To facilitate multiple developers working on the same project.

Prevent conflicts among developers attempting to change the same routine.

To track changes to the code over time.

Configuration and setup

Setup of SourceSafe Client

In order to prevent accidental changes to source code, please make sure when

you install SourceSafe client to mark Use read-only flag for files that are not

checked out as shown below:

VFP will allow you to work fine with files read only. With proper setup in

VFP, (see below), you will be asked to check out any file you wish to modify

as a reminder. If you choose CANCEL, VFP will open the file in read onlymode, thereby protecting the source.


25/30



Setup of SourceSafe integration in VFP

Under tools options, select Projects tab. In the Active source control

provider, select Microsoft Visual SourceSafe. This will open up the lower

portion of the page to allow you to Uncheck all boxes except #2 (Check out

files upon modify) and #5 (Display dialog box for shortcut menu commands)

Very Important


26/30



Setup of Directory Structure on your local harddrive

Everyone needs to create a rns directory on his or her local machine,

preferably the D drive since it is the one with the largest capacity. This willthen become the root-working directory for VFP. Once you join each project,

SourceSafe will automatically create the necessary units, sub-units on your

drive. Once completed, your drive should mirror the rns directory structure

discussed earlier.

How to join a project

From the File menu option, select Join Source Control Project. This will

ask for your password and allow you to join each project. In order to make

sure your directory structure mirrors that of the rns project, please join

projects in the following order:

Rns

Browse to your rns directory on your local drive (d:\rns)

Under the text box Create a new project in folder, select the sub-unit

directory where project exists.

Make sure unchecked

Forced reminder

Make sure unchecked


27/30



Change the Working Directory to your local drive (d:\rns see below).

This will create the rns folder and other folders on your local drive.

General Policies

In order to insure the integrity of the enterprise project, certain policies need

to be adhered to. Because the directory structure for enterprise was created

for maximum flexibility for both developers and SourceSafe, projects and

even files must be added in a certain manner. For now this will be theresponsibility of the team manager.

Below is a list of current policies:

VFP Integration with VSS

SourceSafe interaction MUST be done through VFP. Working through VFP

allows SourceSafe to convert projects, forms, classes and all other binary

files into text files for version comparison.

Read-only files

As per the setup instructions, files on the local drive MUST be read-only

unless checked out. Under no circumstances should the read-only status of a

file be changed without explicit approval of the

New units and sub-units

Only the team manager can create new units and sub-units.


28/30



New files added to Source Control (SourceSafe)

In the current sub-unit

Any team member can add a new file to the project with notification to the

team manager so he can broadcast an e-mail message to other team members

of the need for a refresh of the project.

Outside the current sub-unit

No files outside of the current sub-unit can be added to source code control.

This will invalidate the way SourceSafe refreshes and controls the project.

Offsite work

When checking out files for work off-site, check out the entire sub-unit.

Source Control Procedures

Daily Procedures

Check all files into source control each day, finished or not. This will ensure

backup of files. A WORKING version will be created frequently so as to be

able to refresh a LATEST WORKING version. This is also a good habit to

get into in case you need to back up and go down another path.


29/30



Quality Control

TestingAll code must be tested prior to being released into a production

environment.

Code Reviews

All code must be reviewed before it can be released into a production

environment. Someone other than the author of the code must review the

code.


30/30


General Recommendations

Use SQL rather than xBase syntaxSQL is a widely recognized standard that is support on many platforms.

SQL is also a nonprocedural language that is easier to maintain than

procedural code.

Use objects rather than proceduralcode.

Objects are better encapsulated and easier to reuse than procedural code.

Parameters

If a routine requires a parameter, unless otherwise agreed, pass an object that

contains the required data and let the receiving routine or method determine

how to handle the object.

The 15 minute Rule

If you are stumped on a problem for more than 15 minutes, ASK FOR

HELP!

programming standards guide

Documents