Firstly the naming standard starts with a simple convention for Class Library Objects. These are the basic building block objects that inherit from the PowerBuilder built in objects and extend the functionality of those objects. Most class libraries extend the basic object types and also provide an insulation layer which the end user developer either instantiate or inherits from. The standard for these objects is to use their class identifier followed by _ec for Enterprise Class and _ic for Insulation Class. The Enterprise class is where all of the class library code is placed and the Insulation Layer allows for project level changes. For example:

w_ec - Window Ancestor
w_ic - Window Insulation Layer
ntr_ec - Transaction Object Ancestor ( The n is for Non visual )
ntr_ic - Transaction Object Insulation Layer
dw_ec - Datawindow Control Ancestor
dw_ic - Datawindow Control Insulation Layer

Objects should always be inherited from the _ic object, because of this assumption developers objects can just use the normal object prefix. Objects names should not contain any underscores as you will see later the naming standard uses underscores for a special meaning. For example:

w_mywindow - Window Object inherited from w_ic
ntr_mytransaction - Non visual transaction object inherited form ntr_ic
dw_mydwcontrol - Datawindow Object inherited from dw_ic

These standards cover all of the basic PowerBuilder Objects and are basically the same as the Sybase standards. However many of the objects you develop in PowerBuilder are custom objects. For these objects we need to take the standards further. These custom objects are created by the userobject painter and the naming standard takes its convention from that painter. The two primary types are, visual and nonvisual. You will probably have a much smaller amount of custom visual objects. The custom visual objects inherited from PowerBuilder Objects will be prefixed in the same manner as described above. For custom visual objects the object should be labeled beginning with c_ for custom object. Non visual custom objects should begin with nc_ for nonvisual custom object. Non visual objects that are of type autoinstantiate should be labeled beginning with nca_ for non visual custom object autoinstantiate. This prefix allows the developers to quickly and easily discern the objects type and whether they need to use a create/destroy statement or not.

After the primary custom object identifier comes the name for the object. Try to pick a good strong name that allows the developer to quickly determine the objects purpose especially if many objects will inherit from it. When you inherit from the object carry an identifier that easily identifies the object chain this object inherits from. For example:

nc_ec_service - non visual custom object, enterprise class, ancestor for services
nc_service_window - non visual custom object, inherits from service for window objects
nc_sw_resize - non visual custom object, inherits from service window performs a resize function

In the example above the base object is named nc_ec_service, nc_service_window is inherited from nc_ec_service and is a specialization of the service object for use by window objects. nc_sw_resize is inherited from nc_service_window and is a resize object designed for use with window objects. Some further examples are listed below:

nc_ec_facade - non visual custom object, enterprise class, ancestor for facade's
nc_fcd_list - non visual custom object, inherits from facade for a list object
nc_ec_factory - non visual custom object, enterprise class, ancestor for factories
nc_fac_list - non visual custom object, inherits from factory for creating lists
nca_string - non visual object if type auto instantiate for string functions

For a complete list of object naming standards see the object naming standards list.