System names are largely determined by the customer: consider recommending that the word 'system' should not necessarily be included in the system name.

Once the system has a name a two letter system identifier should be assigned, which is used as a prefix to identify databases, database components and programs created specifically for the system. The two letter identifier should be unique to the installation.

Also create one or more sub-system names and associated two letter identifiers. Each two-letter sub-system identifier should be unique within the system. If you anticipate that your application will need to share application specific global procedures between sub-systems, create a sub-system with the identifier 'gp'. This sub-system should be used for global procedures only.

For example, system Transport Management has identifier tm, with sub-systems Data Maintenance dm and Security Maintenance sm. The combination of the system and sub-system identifier, e.g. tmdm then serves as a prefix for application objects within that sub-system. Refer to the sections below for full details of the naming conventions for different sourcecode types within the sub-system.

Back to Contents

Ingres database names are formed by concatenating the following, separated by underscores:

• An abbreviated version of the customer's name;
• the two-letter system identifier;
• a status identifier;
• the suffix 'db' (not preceded by an underscore).

The status identifiers to be used are as follows; not all these database types need necessarily be used on every project.

Examples:

nc_tm_devdb - Northern Carrier Transport Management development and unit test database

Ingres stores database names in lower case. Upper case names should not be used, although Ingres converts these to lower case.

The DBA owns all but the personal databases which are owned by the developer (created as a private database).

 Back to Contents

Database table names will be in the singular, not the plural, and will be based on the logical entity name. The table name should not exceed 20 characters in length. This will allow any secondary indexes and rules for the table to use the same name with identifying suffix characters.

Where tables relating to two or more separate systems reside in the same database, consider prefixing the table name the two letter system identifier.

Back to Contents

Work or temporary table names are prefixed by the seven characters uniquely identifying the application component (i.e. the four letter system and sub-system code and three digit component identifier), followed by a unique number.

Work or temporary tables are defined as tables created and subsequently dropped by the application, or tables which reside permananently in the database but which are only populated in a transient fashion by the application and thus have no value in business terms.

Back to Contents

Column names are based on the logical attribute name from the Logical Data Model. Names are 24 characters or less in length and include underscore characters to improve readability.

Abbreviated words should be used in column names only where this is required in order to fit the full name within the maximum length. The same abbreviation for a given word should be used throughout the database where that word needs to be abbreviated; this does not however necessarily imply that every occurence of a given word must be abbreviated simply because it is abbreviated in some instances. Abbreviated and non-abbreviated words may be mixed within the same column name if required.

Where abbreviated words are used, they should be formed using the following conventions:

• the first letter should be retained, whether a vowel or a consonant;
• other vowels should be removed;
• one letter of a double consonant should be removed.

Examples:

alwnc - 'allowance'

pnc - 'pence'

cnsmr - 'consumer'

cnsmptn - 'consumption'

trf - 'tariff'

Exceptions to the above conventions are as follows:

• Where a standard or accepted abbreviation using initial letters already exists this should be used, e.g. GMT, MPH, IBM
• For a relatively small number of commonly abbreviated words where a more intuitive abbreviation exists this should be used as long as there is no ambiguity, e.g. min for minimum, max for maximum, mon for Monday, feb for February.

The column name must contain an indication of the domain as a suffix. Where the domain is unambiguous, e.g. postcode, this can be omitted. Generic suffixes are:

Examples:

Back to Contents

Columns which have the same definition and identical meanings should have the same name.

For example, financial_year on one table should not be called financial_yr or accounting_year on another table (or system).

Back to Contents

Columns which do not have the same definition and do not have identical meanings should NOT have the same name.

For example, a column called cleared_by on one table might be used to hold the date on which an order was cleared. On another table we might wish to hold the name of the person responsible for clearing the order. The column on this second table must NOT be called cleared_by because the meaning and probably the definition is different in each case.

Homonyms can be accidentally created when the context of an attribute changes due to it being included as a column on another table. To avoid this, ensure that a column name's meaning is also clear outside the context of the table. For example, avoid column names such as description or total.

Back to Contents

Views are given a meaningful name using underscores for readability, and suffixed by '_vw'.

Example:

cmpttr_trf_vw - View of competitors' tariffs

Back to Contents

Secondary index names consist of the table name that the index is used for, suffixed by '_i<nn>' where <nn> is the index number, starting at 01, for that table.

Examples:

trf_version_i01 - The first index on table trf_version

trf_dscnt_i03 - The third index on table trf_dscnt

Back to Contents

Database rule names are given a meaningful name (normally the table name), suffixed by '_<x>rul', where the character 'x' is u, i, d or c indicating an update, insert, delete or combination.

Example:

unit_charge_urul - Rule that triggers on update of table unit_charge

Back to Contents

Database procedure names are given a meaningful name using underscrores for readability, suffixed by '_pr'.

Example:

calc_unit_charge_pr - Database procedure calculating unit charges

Back to Contents

Database events are given a meaningful name using underscrores for readability, suffixed by '_ev'.

Example:

print_request_ev - Database event signifying a print request.

Back to Contents

OpenROAD application names consist of the two-letter system identifier code followed by a short, meaningful description of the application using underscores for readability. (The two-letter sub-system identifier is not used in the application prefix as it is common in OpenROAD applications to place application components for several sub-systems within a single physical application.)

Example:

TM_Business_Objects - application containing the business objects for the Transport Management system

Back to Contents

Frame and global procedure names are derived by concatenating the following:

• The 4 character system and sub-system identifier (lower case);
• a 4 digit identifier unique within the sub-system;
• a short mixed case description preceded by an underscore.

Examples:

tmdm0130_TaxDetail - frame in Transport Management used to maintain tax details;

tmgp0090_LoadStaticLists - global procedure used by all Transport Management sub-systems to load static lists

The 4-digit identifiers used should follow in sequence where the components are related. Use steps of ten between component groups.

Examples:

tmdm0130_TaxDetail - detail frame for tax details (this component group starts at 0130)

tmdm0134_TaxList - list frame for tax details

tmdm0138_TaxSearch - search frame for tax details

tmdm0140_TimebandDetail - detail frame for timeband details

Note that no identifier is used in the name to distinguish between frames and global procedures within a sub-system as this information is readily available from the Component Catalog.

Back to Contents

As with frame and procedure names, include script names must be unique within eight characters. The names are derived by concatenating the following:

• The 4 character system and sub-system identifier (lower case);
• a 4 digit unique identifier;
• the identifier '_is';
• a short mixed case description preceded by an underscore.

Include script 4-digit identifiers should follow on directly from the number used for the frame or global procedure which uses them.

Examples:

tmdm1101_is_PostOk - First Include script for tmdm1100_TransportDetail

tmdm1102_is_PreNewDisplay - Second include script for tmdm1100_TransportDetail

Back to Contents

Local procedures in OpenROAD are defined as procedures which are private to a given frame or global procedure. Local procedure names consist of two or more words describing the function the procedure performs; the name is written in mixed case without underscores.

Example:

ValidateCharges - local procedure which validates tariff charge data

Note that to avoid confusion, different naming conventions exist for local and global procedures.

Back to Contents

User class names are formed by concatenating the following:

• The prefix 'uc_' for user class;
• a meaningful lowercase name using underscores for readability;
• a type suffix from the list below.

Possible user class type suffixes are as follows. Note that the suffixes use the generic object orientation term 'business class'.

Examples:

uc_timeband_bc - Business class used to hold details of timebands

uc_timeband_list_bc - List class holding a list of instances of uc_timeband_bc

uc_timeband_searchcrit_bc - Search criteria to populate uc_timeband_list_bc

uc_timeband_gc1 - GUI class number 1 for additional display items for uc_timeband_bc

uc_timeband_gc2 - GUI class number 2 for additional display items for uc_timeband_bc

uc_timeband_coverage_bs - Business structure used to validate timeband coverage

uc_timeband_coverage_gs1 - GUI class number 1 for additional display items for uc_timeband_coverage_bs

uc_app_func_detail_fs - Function structure holding the details of a given application function as used by the application function class list uc_app_func_list_fc

Back to Contents

The following conventions are used to indicate frame or procedure variables whose datatype is a user class:

Examples:

UCSupplier - variable of type uc_supplier_bc

UCSupplier_tmp - variable of type uc_supplier_bc

UCSupplierList - variable of type uc_supplier_list_bc

UCSupplierSearchCrit - variable of type uc_supplier_searchcrit_bc

DUCSupplier - dynamically created variable of type uc_supplier_bc

arr_UCSupplier - array of type uc_supplier_bc

Where system class composites are used to display objects based on a user class, the appropriate composite field prefix can be placed before the object field name. Note that this prefix must not be used when the field is nested within a class-mapped composite. See section 6.10 for a list of common system class prefixes.

Examples:

mtx_UCSupplier - matrix field used to display uc_supplier_bc

stk_UCSupplier - stack field used to display uc_supplier_bc

Back to Contents

Variables of simple data types used in frames, global procedures and userclass methods are not prefixed with a scope indicator. These variables are formed by concatenating the following:

• a datatype indicator prefix;
• a meaningful description using underscores for readability.

The following prefixes are used to indicate simple datatypes:

Examples:

i_ retval - variable of type integer used for return code

d_effective_from - variable of type date used for an effective date

v_trf_desc - variable of type varchar used for a tariff description.

When using 'well known' variable names, such as i and j (usually used as loop counters), the type can be omitted. Such variables should have a short life, i.e. the value should have meaning within a very limited context of the program only. It must be stressed that this exception is for a small number of variables only.

Back to Contents

Global constants and variables have the scope of an entire application, i.e. all frames, user class methods and global procedures. The most commonly used globals use the simple datatypes listed in the previous section; however, they may also use the special datatypes as explained in a later section. Global constants and variables with simple datatypes are formed by concatenating the following separated by underscores, written in upper case:

• The prefix 'GV' indicating a global variable or 'GC' indicating a global constant;
• a datatype indicator from the list in the previous section;
• a two-character abbreviation showing the domain or area of functionality;
• a meaningful description using underscores for readability.

Examples:

GC_I_ST_INITIAL - global constant of datatype integer, within domain 'state', meaning 'initial'

GV_V_FQ_DAILY_TXT - global variable of datatype varchar, within domain 'frequency', meaning 'text string for daily'.

Back to Contents

All system classes allow you to create objects as a reference variable based on the class in a script. Some system classes (e.g. ButtonField, StackField) also allow you to create objects on a form on based on the system class.

As confusion may arise for the classes which allow you to create objects in both ways, two naming conventions are used for system class objects in order to allow you to distinguish between the objects created in the two ways.

The first of these two naming conventions is used for:

• objects on a form;
• objects created as reference variables based on system classes which do not allow you to create objects on a form, that is where no ambiguity may exist.

These objects are named by concatenating the following separated by underscores, written in lower case:

• a system class prefix (see lists);
• a meaningful name using underscores for readability.

Examples:

btn_ok - button field on the form meaning 'OK'

tgl_energy_type - toggle field on the form meaning energy type

cl_trf_category - reference variable of type ChoiceList used for a list of valid tariff categories

fe_energy_type_popup - reference variable of type FrameExec used to hold a pointer to a popup frame allowing the user to choose an energy type.

The second of these two naming conventions is more rarely required; it is used for:

• system class FieldObjects created as reference variables (i.e. not as a field on a form).

These objects are named by concatenating the following separated by underscores, written in lower case:

• the prefix 'r' indicating a reference variable;
• a system class prefix (see lists);
• a meaningful name using underscores for readability.

Examples:

rtgl_gmt_ind - reference variable of type toggle field holding a GMT indicator

rbtn_display_type - reference variable of type button field holding a display type indicator.

Back to Contents

Commonly used system classes are shown below with their prefixes. A full list of system class prefixes is given in Appendix A. The table also shows whether each class allows you to create objects on a form.

Some further very common system classes may be used to create fields on forms, different instances of which may be defined as being of different datatypes. Therefore, these system class prefixes also include a datatype indicator after the class prefix itself. The system classes to which this applies are as follows:

The x indicates a datatype indicator is one of the list shown in section 6.7. All this is illustrated below.

Examples:

sefi_trf_cd - Singleline entry field of type integer holding a tariff code

sefv_category_nm - Singleline entry field of type varchar holding category name text

mefv_trf_desc - Multiline entry field of type varchar holding a tariff description

rdoi_payment_type_cd - Radio field of type integer holding a payment type code

lsti_timeband_cd - List field of type integer containing a timeband code

opti_supplier_cd - Option field of type integer containinga supplier code

Remember that as stated in section 6.6, if any other system class variable, eg. a table field, is assigned a data type of a user class, then the data type should be included in the variable declaration.

Examples:

tf_UCsltlst_tmp - a TableField with a type of user class uc_sltst_bc

arr_UCsltlst_tmp - array with a type of user class uc_sltst_bc

Back to Contents

User class attributes names reflect their data type, which may be a simple data type, a system class or a user class. Thus, user class attributes are named according to the conventions used for naming variables of simple data types (see section 6.7), for naming objects based on system classes (see section 6.9) or for naming objects based on user classes (see section 6.6). (When naming attributes based on system classes, the 'r' prefix as described in section 6.9 is unnecessary.)

Where an attribute holds data from a given database table column, the attribute should have the same name as the column, prefixed by the relevant data simple type (as no char data type exists for attributes, char columns are held as varchar attributes; similarly, only smallint and integer are supported, so integer1 and integer2 columns are held in smallint attributes, and integer4 columns in integer attributes).

Examples:

i_trf_category_id - Attribute of type integer holding column trf_category_id

v_amendment_desc - Attribute of type varchar holding column amendment_desc

i_has_trf_notes_changed - Attribute of type integer containing an internal flag

s_competitor_no - Attribute of type smallint holding a competitor number

UCTariffDiscountDetails - Attribute of type uc_tariff_discount_bc

arr_UCTrfStatusHistory - Array attribute of type uc_trf_status_history_bc

bo_gas - Attribute of type BitMapObject holding a gas image.

Back to Contents

User class methods are given meaningful names and written in mixed case without underscores. Where a method accesses the database the name is prefixed by 'DB'.

Examples:

CheckFullNameUnique - Method to validate a name item

DBFullyPopulate - Method to access the database to fully populate an object.

Back to Contents

A local variable is a variable whose scope or visibility is one of the following:

• a local procedure used within a frame script;
• a local procedure used within a global procedure;
• a local procedure used within a user class script;
• a method in a user class script;
• a field script.

The local scope of the variable (as opposed to variables global to a frame or global procedure) is shown by a prefix. Local variables are formed by concatenating the following separated by underscores:

• Scope indicator 'l';
• datatype from the list in 6.7;
• a meaningful name using underscores for readability.

Examples:

l_i_cum_charge - Local variable of type integer holding a cumulative charge

l_v_category_sav - Local variable of type integer holding a saved category

Back to Contents

When a variable is being used as a parameter is passed to a local procedure or to a method, this is indicated by a prefix. Parameter variables are formed by concatenating the following, separated by underscores:

• Type indicator 'p' for parameter passed by value, or 'b' for parameter passed BYREF;
• either a simple datatype from the list in 6.7 or a system class prefix;
• a meaningful name using underscores for readability.

Examples:

p_c_trf_category - parameter variable of type char indicating tariff category, passed by value

b_i_tot_charge - parameter variable of type integer holding a total charge, passed by reference.

p_fe_tariff_popup - parameter variable of type FrameExec holding a pointer to a popup frame, passed by value

b_arr_UCSupplier - parameter variable of type array of uc_supplier_bc, passed BYREF.

Back to Contents

Prefixes can be combined using the formats specified in sections 6.6 to 6.14 in conjunction with the following rules:

• The global scope prefixes (ie. GC and GV) can only be combined with simple data types ('c_', 'd_', etc) and the prefixes used for variables based on user classes (ie. arr_, UC, DUC, UCOF_);
• When a system class reference variable is being declared then the 'r' prefix is not required when it is implied by the use of one of the global scope prefixes, the local variable prefix or one of the parameter variable prefixes.

Examples of combined prefixes are shown below.

Back to Contents

The following list shows each System Class with its prefix which should be used for fields declared on the form. An 'r' should be added to this prefix to indicate a reference variable declared in the script for classes which are also definable as a field on a form.

Back to Contents