Download - Programming Standards Guide
-
8/6/2019 Programming Standards Guide
1/30
Programming Standards 1999 PDS ConfidentialRnS.dot Version 1.3
Programming
Standards andConventions
Guide
-
8/6/2019 Programming Standards Guide
2/30
March 2, 1999 Programming Standards and Conventions Guide Page 2
Programming Standards 1999 PDS ConfidentialRnS.dot Version 1.3
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.
-
8/6/2019 Programming Standards Guide
3/30
March 2, 1999 Programming Standards and Conventions Guide Page 3
Programming Standards 1999 PDS ConfidentialRnS.dot Version 1.3
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.
-
8/6/2019 Programming Standards Guide
4/30
March 2, 1999 Programming Standards and Conventions Guide Page 4
Programming Standards 1999 PDS ConfidentialRnS.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 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:
-
8/6/2019 Programming Standards Guide
5/30
March 2, 1999 Programming Standards and Conventions Guide Page 5
Programming Standards 1999 PDS ConfidentialRnS.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-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.
-
8/6/2019 Programming Standards Guide
6/30
March 2, 1999 Programming Standards and Conventions Guide Page 6
Programming Standards 1999 PDS ConfidentialRnS.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 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:
-
8/6/2019 Programming Standards Guide
7/30
March 2, 1999 Programming Standards and Conventions Guide Page 7
Programming Standards 1999 PDS ConfidentialRnS.dot Version 1.3
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/6/2019 Programming Standards Guide
8/30
March 2, 1999 Programming Standards and Conventions Guide Page 8
Programming Standards 1999 PDS ConfidentialRnS.dot Version 1.3
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.
-
8/6/2019 Programming Standards Guide
9/30
March 2, 1999 Programming Standards and Conventions Guide Page 9
Programming Standards 1999 PDS ConfidentialRnS.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
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 -
8/6/2019 Programming Standards Guide
10/30
March 2, 1999 Programming Standards and Conventions Guide Page 10
Programming Standards 1999 PDS ConfidentialRnS.dot Version 1.3
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
-
8/6/2019 Programming Standards Guide
11/30
March 2, 1999 Programming Standards and Conventions Guide Page 11
Programming Standards 1999 PDS ConfidentialRnS.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:
#define EXECUTIONLOG \E:
#else
#define DEBUGLOG *
#define EXECUTIONLOG \E:
#endif
* ----------------------------------------------------------- *
* Default paths to sub-units
-
8/6/2019 Programming Standards Guide
12/30
March 2, 1999 Programming Standards and Conventions Guide Page 12
Programming Standards 1999 PDS ConfidentialRnS.dot Version 1.3
* >---------------------------------------------------------- *
#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'
-
8/6/2019 Programming Standards Guide
13/30
March 2, 1999 Programming Standards and Conventions Guide Page 13
Programming Standards 1999 PDS ConfidentialRnS.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'
*
-
8/6/2019 Programming Standards Guide
14/30
March 2, 1999 Programming Standards and Conventions Guide Page 14
Programming Standards 1999 PDS ConfidentialRnS.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-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:
-
8/6/2019 Programming Standards Guide
15/30
March 2, 1999 Programming Standards and Conventions Guide Page 15
Programming Standards 1999 PDS ConfidentialRnS.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:
-
8/6/2019 Programming Standards Guide
16/30
March 2, 1999 Programming Standards and Conventions Guide Page 16
Programming Standards 1999 PDS ConfidentialRnS.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,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:
-
8/6/2019 Programming Standards Guide
17/30
March 2, 1999 Programming Standards and Conventions Guide Page 17
Programming Standards 1999 PDS ConfidentialRnS.dot Version 1.3
-
8/6/2019 Programming Standards Guide
18/30
March 2, 1999 Programming Standards and Conventions Guide Page 18
Programming Standards 1999 PDS ConfidentialRnS.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
rectangle, rounded square)
shpCircle
spn Spinner spnValues
txt TextBox txtGetText
tmr Timer tmrAlarm
Tbr ToolBar tbrEditReport
-
8/6/2019 Programming Standards Guide
19/30
March 2, 1999 Programming Standards and Conventions Guide Page 19
Programming Standards 1999 PDS ConfidentialRnS.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 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 )
-
8/6/2019 Programming Standards Guide
20/30
March 2, 1999 Programming Standards and Conventions Guide Page 20
Programming Standards 1999 PDS ConfidentialRnS.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
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
-
8/6/2019 Programming Standards Guide
21/30
March 2, 1999 Programming Standards and Conventions Guide Page 21
Programming Standards 1999 PDS ConfidentialRnS.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 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:
-
8/6/2019 Programming Standards Guide
22/30
March 2, 1999 Programming Standards and Conventions Guide Page 22
Programming Standards 1999 PDS ConfidentialRnS.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 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.
-
8/6/2019 Programming Standards Guide
23/30
March 2, 1999 Programming Standards and Conventions Guide Page 23
Programming Standards 1999 PDS ConfidentialRnS.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 thecode.
-
8/6/2019 Programming Standards Guide
24/30
March 2, 1999 Programming Standards and Conventions Guide Page 24
Programming Standards 1999 PDS ConfidentialRnS.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 onlymode, thereby protecting the source.
-
8/6/2019 Programming Standards Guide
25/30
March 2, 1999 Programming Standards and Conventions Guide Page 25
Programming Standards 1999 PDS ConfidentialRnS.dot Version 1.3
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
-
8/6/2019 Programming Standards Guide
26/30
March 2, 1999 Programming Standards and Conventions Guide Page 26
Programming Standards 1999 PDS ConfidentialRnS.dot Version 1.3
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
-
8/6/2019 Programming Standards Guide
27/30
March 2, 1999 Programming Standards and Conventions Guide Page 27
Programming Standards 1999 PDS ConfidentialRnS.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 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.
-
8/6/2019 Programming Standards Guide
28/30
March 2, 1999 Programming Standards and Conventions Guide Page 28
Programming Standards 1999 PDS ConfidentialRnS.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.
-
8/6/2019 Programming Standards Guide
29/30
March 2, 1999 Programming Standards and Conventions Guide Page 29
Programming Standards 1999 PDS ConfidentialRnS.dot Version 1.3
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.
-
8/6/2019 Programming Standards Guide
30/30
March 2, 1999 Programming Standards and Conventions Guide Page 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!