Programming Standards Guide

Programming
Standards and
Conventions
Guide
Programming Standards © 1999 PDS Confidential

RnS.dot Version 1.3
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 the
development 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 the
standards 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 point
in 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.

RnS.dot Version 1.3
Development Environment
Conventions
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 of
code 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.

RnS.dot Version 1.3
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 the
metadata 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 actual
sources 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:

RnS.dot Version 1.3
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-data
and 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 processed
by 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 organize
the 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.

RnS.dot Version 1.3
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 change
the 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 files
that are common to all units as well as to the developers own local work
directory.
This path breaks down as follows:

RnS.dot Version 1.3
Path Description
d:\work Local work directory

Classes Relative path to the sub-unit’s classes directory
Forms Relative path to the sub-unit’s forms directory
Prgs Relative path to the sub-unit’s programs directory
Reports Relative path to the sub-unit’s reports directory
Sql Relative path to the sub-unit’s sql directory
..\ Relative path to the sub-unit’s 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 to
delete 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 part
the 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.

RnS.dot Version 1.3
Configuration
Required Options dialog configuration

settings
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 dialog

configuration settings
The following options are optional but suggested.

RnS.dot Version 1.3
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 Off
running form
Controls Selected Rnswizard
Label Wizards
Syntax Coloring Comments Green, Bold
Keywords 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 the j:\dev\rns\common\fpw directory.
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

RnS.dot Version 1.3
Programming Conventions
Header Files & Constants

Predefined 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 following
statements:
#define localHloaded "Yes"
#define ENTERPRISEPATH pathtoenterprisedirectory

#define ENTERPRISEDATAPATH pathtoenterprisedatadirectory
#define ENTERPRISEINBOXPATH pathtoenterpriseinboxdirectory
The localHloaded constant is used to verify that the header file is being
loaded when a program is compiled.
The ENTERPRISEPATH constant defines path where this workstation finds the
enterprise source files. The value pathtoenterprisedirectory 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 value pathtoenterprisedatadirectory 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 value pathtoenterpriseinboxdirectory 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

RnS.dot Version 1.3
#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

RnS.dot Version 1.3
* >---------------------------------------------------------- *
#define LOADPATH "load\"
#define METAPATH "meta\"
#define PRODPATH "prod\"
* <---------------------------------------------------------- *
* ----------------------------------------------------------- *
* ///////////////////////// UNITS \\\\\\\\\\\\\\\\\\\\\\\\\\\ *
* ----------------------------------------------------------- *
* ----------------------------------------------------------- *
* Gears Unit
* >---------------------------------------------------------- *
* 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'

RnS.dot Version 1.3
* 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'
* <---------------------------------------------------------- *
The enterprise header file must include the VFP header file foxpro.h so that
all routines have access to these predefined constants. The enterprise header
file must also include the local header file so that the enterprise can be
located.
In this example the default sub-unit paths are defined, followed by the most
commonly used paths within each sub-unit. Next the Unit path is defined
using the enterprise path from the local header file. The full sub-unit paths
are defined using the defaults and this is followed by the definition of the
most commonly used subdirectories within each sub-unit.
These definitions would be repeated for each unit in the enterprise changing
the name of the unit.
Unit Header Files

The unit header file constants that are common to a specific unit within the
enterprise. The unit header file is located in the unit directory. The following
must be included in every unit header file:
#include enterprise.h
#define UnitHLoaded "Yes"
The unit header file must include the enterprise header file so that the
enterprise paths can be defined..
Sub-unit Header Files

The sub-unit header file constants specific to a sub-unit within a unit. The
sub-unit header file is called subunit.h and is located in the sub-unit
directory. The following must be included in every sub-unit header file:
#include unit.h
#define SubunitHLoaded "Yes"

RnS.dot Version 1.3
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-unit’s

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 in
any unit or sub-unit.
If the code is part of a unit or sub-unit component then the #include should
reference 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 the
header 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:

RnS.dot Version 1.3
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:

RnS.dot Version 1.3
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, lcLastName
Memo
y Currency lyCurrentValue
d Date tdBirthDay
t Datetime vtLastModified
l Logical rlFlag
n Numeric, lnCounter
Double,
Integer,
Float
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:

RnS.dot Version 1.3

RnS.dot Version 1.3
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 shpCircle
rectangle, rounded square)
spn Spinner spnValues
txt TextBox txtGetText
tmr Timer tmrAlarm
Tbr ToolBar tbrEditReport

RnS.dot Version 1.3
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 named Id
• Prefix any foreign key fields with the foreign key table name followed by
Id… 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 )

RnS.dot Version 1.3
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 Example
following:
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

RnS.dot Version 1.3
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 the
person 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 for
the code as it exists. If your name is associated with a piece of code,
hopefully you’ll 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:

RnS.dot Version 1.3
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 clearer
more 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 to
change 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 error
should 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.

RnS.dot Version 1.3
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 the
code.

RnS.dot Version 1.3
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 only
mode, thereby protecting the source.

RnS.dot Version 1.3
Very Important
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)

RnS.dot Version 1.3
Make sure unchecked
Forced reminder
Make sure unchecked
Setup of Directory Structure on your local hard

drive
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 will
then 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.

RnS.dot Version 1.3
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 the
responsibility 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.

RnS.dot Version 1.3
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.

RnS.dot Version 1.3
Quality Control
Testing
All 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.

RnS.dot Version 1.3
General Recommendations
Use SQL rather than xBase syntax

SQL 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 procedural

code.
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!

RnS.dot Version 1.3

Programming Standards Guide

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Programming Standards Guide

Încărcat de

Drepturi de autor:

Formate disponibile

Programming

Programming Standards © 1999 PDS Confidential

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

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

Programmers found to be repeatedly in violation of these standards and

Programming Standards © 1999 PDS Confidential

The following figure shows a sample development directory structure for

Programming Standards © 1999 PDS Confidential

Programming Standards © 1999 PDS Confidential

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

Programming Standards © 1999 PDS Confidential

Default Directories and Paths

Whenever a path is used, a relative paths should be used whenever possible.

In development the following or similar path should be used:

This path breaks down as follows:

Programming Standards © 1999 PDS Confidential

d:\work Local work directory

Programming Standards © 1999 PDS Confidential

Required Options dialog configuration

Tab Option Setting

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

Suggested Options dialog

Programming Standards © 1999 PDS Confidential

Tab Option Setting

Data Automatic file locking On

Required configuration file settings.

Programming Standards © 1999 PDS Confidential

Header Files & Constants

The Local Header File

#define ENTERPRISEPATH pathtoenterprisedirectory

The ENTERPRISEDATAPATH constant defines path where this workstation finds

The ENTERPRISEINBOXPATH constant defines path where this workstation finds

The Enterprise Header File

Programming Standards © 1999 PDS Confidential

#define EnterpriseHLoaded "Yes"

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

#define TRUE .t.

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

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

#define DEVDEPLOYMENTMODE 'DEV'

* Change this definition to one of the above definitions and

#if DEPLOYMENTMODE = DEVDEPLOYMENTMODE

Programming Standards © 1999 PDS Confidential

* Load sub-unit working directories

* Meta sub-unit working directories

* Prod sub-unit working directories

* DBC file names

Programming Standards © 1999 PDS Confidential

* DBC file specifications

* Project file specifications

Unit Header Files

#define UnitHLoaded "Yes"

Sub-unit Header Files

#define SubunitHLoaded "Yes"

Programming Standards © 1999 PDS Confidential

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

Including header files in code

What file to include?

Memory Variables and Constants

Programming Standards © 1999 PDS Confidential

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

Expressions for Scope are as follows:

Scope Description Example