PegaRULES Process Commander (PRPC) naming standards
Naming Standards
General
· Names should reflect the purpose of the rule and should be self-explanatory.
· Use a patterned naming convention to relate rules.
· Names can only contain letters and numbers.
· Names should be kept short, but not so short that the purpose of the rule is not evident.
· Names should start with capital letters. Words within names should start with capital letters. Acronyms within names should be capitalized. (File names are an exception to this. See below for more information.)
· Keep meaningless verbiage out of rule names, like “Citi”. We all know by now that we are at Citi.
· Except as noted below, names should not include underscores or other special characters. Use the “camel” naming convention where you capitalize the first letter of each word.
· Names of “active” rules such as Activities and Flows should start with a verb indicating the main action of the rule and should generally include a noun or noun phrase indicating what the rule operates on.
· Names of “passive” or “object” rules, such as parameters, properties, work parties, libraries, and roles, should be nouns or noun phrases indicating the use of the rule.
· NEVER create the same exact rule in a different class. If it needs to be in a higher class, move it, don’t copy it.
Rulesets
· Rule Set names should start with Name-Application Name. For Instance
o CitiRules :01-01-01
· Do not name a ruleset starting with Pega-.
Classes
· Top level classes Citi- contains all the Reusable components which extends @baseclass which is in CitiRules Rule Set
· All classes extend Citi-. For instance: Citi-Card-.
· Do not name a class starting with Pega-.
· Class names should follow the capitalization standards above. Class names should be nouns or noun phrases describing the use of the class. The names of abstract classes should end with a dash. Class names should not contain underscores.
· Names should support pattern inheritance as well as directed inheritance.
· Abstract class names should end with a dash.
· Subclasses should include the names of all parent classes to support pattern inheritance.
Activities
In general, these names should start with a verb indicating what the activity does. Most of these names should also contain a noun or noun phrase indicating what the activity operates on. For instance:
Create, Delete – Tolerable, but too generic
CreateClassPage, GetHTMLFilePath, AddPageIndex– Good
Toolbar_ChangeAvailability – Good; demonstrates leading functional group name
HarnessShow – Bad. Doesn’t start with verb.
New – Bad. Not a verb; provides insufficient information.
AllCompleted – Bad. Describes how you got to the activity, not what it does.
Flow Actions
Names of FlowActions (and associated HTML) should start with “Action”.
Validation Rules
· Start with “Validate”.
· Names of activities of type Rule-Obj-Validate should start with “On” and describe the situation in which the validation occurs, e.g., “OnAdd”, “OnRuleSave”.
· Validation rules should not require on-going maintenance. For instance, if you want to validate a property against a list of possible values and new values may be added frequently. A validation rule is not the best solution because of this on-going maintenance.
Routing Activities
· Router activities should start with “To” and end in a noun phrase indicating the route destination, e.g., “ToWorkbasket”.
Functions
· Names of functions (Rule-Utility-Function) should follow Java naming standards (initial lower case, then mixed case), since they are actually Java functions.
Properties
· Property names should be nouns or noun phrases that describe the property. Names of lists (StringList, PageList) should end in “List”. Names of groups (StringGroup, PageGroup) should end in “Group”.
· Property names defined by Pega are prefixed with “px”, “py”, or “pz”.
· User-defined property names must not start with these prefixes.
· Use Single-word, meaningful names with significant letters in uppercase.
· Choose similar names for related properties.
· Don’t use same property name to represent different things in different classes.
Models
· Model should usually be named pyDefault if you want to be able to utilize the models of super-classes.
· If you are not using pyDefault, make sure the name you choose is meaningful and describes the purpose.
Flows
· Flow names should describe the overall purpose of the flow. Follow general naming guidelines defined above.
Whens
· Rule-Obj-When instances should have names that could logically follow the word “when”. For instance:
a. IsBlank, StepStatusGood, NotThisClass – Good. Each of these makes sense after “when”.
b. AdministratorID, Unlock – Bad. Meaning unclear in the context of “when”.
c. WhenZero – Bad. “IsZero” would be better.
Files
· Files under Rule-File- should be all lowercase. (This avoids confusion between systems like Unix that have case-sensitive filenames and systems like Windows that don’t.) It is recommended that names of files used for related functions begin with the same prefix characters so that they will be grouped together in listings.
HTML Streams
· Stream names should be nouns or noun phrases that indicate the main data displayed by the stream. If possible, this name should relate to the name of the activity, action, etc., that displays the stream.
Tickets
· Ticket names should describe the condition to be met before processing continues from the ticket. For example:
a. AllCoveredResolved
b. WorkWithdrawn
MQ Connector Rules
· MQ Connect rules should always start with “MQ”. Otherwise, follow general naming guidelines above.
