Naming Conventions
Buffers and Temp-Tables
DEFINE BUFFER {Buffer-Name} FOR Customer.
DEFINE TEMP-TABLE ttCustomer NO-UNDO LIKE Customer.
When defining a buffer or a temp-table the name should be build out of the role of the buffer or temp-table in the current context and the table name of the related database or temp-table as a prefix.
{Buffer-Name} -> SourceCustomer
If we now add a column name as shown below this provides an effective advantage when searching for all occurrences of a column name of a table.
SourceCustomer.CustNum
This is a nice to have rule. So exceptions are o.k.
Before-Tables defined for ProDataset temp-tables do not follow this form. As before-tables and after-tables (the normal temp-table name) are typically used in the same context it is considered that this makes code easier readable.
Type Prefixes
Type | Prefix | Possible alternative name |
|---|---|---|
INTEGER | i | i j n m |
INT64 | i |
|
DECIMAL | de |
|
DATE | da |
|
DATETIME | dt |
|
DATETIME_TZ | dtz |
|
CHARACTER | c |
|
LONGCHAR | lc |
|
HANDLE | h |
|
COM-HANDLE | ch |
|
LOGICAL | l |
|
RECID | re |
|
ROWID | ro | row_id, rowId |
MEMPTR | m |
|
Progress.Lang.Object (and derived) | o |
|
Nomen nest Omen – names should specify what they are used for. It is considered a better practice to define two explicitly named variables rather than reusing a variable with an unclear name “just because it’s no longer needed in the original context”.
The variable names [i, j, n, m] are allowed as loop counters (INTEGER).
Must-have rule: If the variable names are short then only those four names should be used.
Should Rule: If there are nested loops then the pairs of i + j and n + m should be used.
Parameter Prefixes
While passing a variable to a procedure or defining a parameter the direction (INPUT / OUTPUT / INPUT-OUTPUT) it is preferred not to specify the INPUT option. It’s common to most development systems that the default parameter direction is INPUT.
Inside a procedure / function / method parameter names will be prefixed (before the data type prefix) with a lower case p.
In property SET methods, the parameter name may remain “arg” as suggested by the OpenEdge Architect wizard.
Usage: | Sample | Description |
|---|---|---|
Variable: | daAppointmentDate | Datatype as prefix |
Parameter: | pdaAppointmentDate | p{arameter} plus datatype as prefix |
In the default CATCH block template provided by Progress Developer Studio it is o.k. to use the name “err” for the error being caught. In cases where multiple CATCH blocks for different error types are needed in a routine-level block it is recommended to use the normal naming rules for error objects (oException, oNotSupportedException, ...).
The name of variables used for Object references should allow to guess the type name of the referenced objects.
oForm, oParentForm oBusinessEntity
If the context makes it clear which “type” on object is from, it is o.k. to name reference variables based on the context only:
Sample | Description |
|---|---|
oCustomerDataset | o.k. for CustomerDatasetModel |
oCustomer | o.k. for CustomerTableModel |
Class Names
Class names should use the name of the most relevant base class as a suffix in their name to increase descriptiveness:
Samples:
CustomerBusinessEntity CustomerDataAccess CustomerDatasetModel CustomerTableModel CustomerForm (from SmartWindowForm which is a Form) WeekdayEnum
Classes that are used as parameter objects only to specific method of another class should be named as ...Parameter, samples:
ShipOrderParameter YearEndReportParameter
When these parameter objects actually inherit from Consultingwerk.JsonSerializable, it is considered better practice to qualify those class names as “Parameter” objects than as “Serializable” (as serializable objects are typically used as parameters for AppServer calls).
Interface Names
Interface type names will be prefixed with a capital I.
Method Names
Method and Class names begin with a capitalized letter. Variable names begin with a lower case letter.