Naming conventions make programs more understandable by making them easier to read. In addition to the Java naming conventions, Pricefx has its own set of recommended naming conventions for logics and metadata.
Logic Names
Logic names should be written in CamelCase.
Examples:
- DefaultLogic
- Pricelist
- Main
- DefaultQuoteLogic
However, there are a few exceptions; the following logic types should be written with the following prefixes:
Logic type | Formula Nature | Prefix | Suffix | Example |
---|---|---|---|---|
Calculation Flow | calculationFlow | CF_ | CF_DailyCalculation | |
Calculated Field Set | null /(default) | CFS_ | CFS_ProductEnrichment | |
Dataload | "paDataLoad" | DL_ | DL_LoadFromPX | |
Groovy Library |
| Lib | SharedLib |
Element Names
Whenever an identifier is required (uniqueName, name, etc.), it is recommended to use identifiers in a ClassicalCamelCaseFormAsYouKnowItFromJava, e.g. SalesPrice. If there is a abbreviation used in the name, it is naturally useful to separate it with an underscore character "_", for example, ABC_Class (instead of ABCClass).
Labels are typically a copy of the uniqueName/name and the words are split using spaces, e. g. Sales Price.
Here are some commonly used conventions for the identifier suffixes:
Suffix | Example | Label | Meaning |
---|---|---|---|
Diff | VolumeDiff | Volume ∆ | Represents the difference between an actual and previous value |
Abs | MarginAbs | Margin $ | Margin represented as an amount (typically formatted as Money) |
Pct | MarginPct | Margin % | Margin represented as a percentage (typically formatted as Percent) |
s | pxRecords | Represents a list of values |
The suffixes can be combined.
Element Names
The general rule is to make the first letter uppercase. The reason is that the element is implemented as a Groovy class and therefore referring to the element's methods from Groovy is done as SomeElement.callSomeMethod(). For this syntax the auto-completion will work in Pricefx Studio, since IDEA will understand it as a static call of a method (even though it is not a static call but an instance call on a binded object). Another reason for the first capital letter is to have the possibility to refer to previous elements: - PM-284Getting issue details... STATUS
In order to make the auto-completion work in Pricefx Studio or to be able to run the debugging functionality or execute TDD4C tests without marking the folders as a source in Studio, it is recommended to always use a different element name which is unique within the project. Also the element name "Filter" is not recommended, since the auto-completion collides with the standard Filter object used frequently by the logics.
The Groovy library element names should have a suffix "Utils" (e.g. RoundingUtils, CacheUtils, DatamartUtils).
Example: NewMargin, SalesPrice
Element Labels
Element labels make sense to set only if the element can be displayed to the user. Labels are not visible for elements with Display=Never or not selected in PL or LPG, so it doesn't make much sense to define the labels for those type of elements.
Element labels should ideally match the element name where just spaces are added and each word starts with a capital letter (commonly used pattern in UK or US).
The element label should not be identical to a different element name or field name, since functions accept both label and element.
The basic rule is that labels can be adjusted at any point in time and so you should not refer to labels in the logic, instead use the element name or attribute.
Groovy Variables
The general rule is to make the first letter lowercase. Even though Groovy, compared to Java, allows the first letter in uppercase, it is recommended to follow the Java convention.
Example: newMargin, salesPrice
If the variable stores a list of values, then the suffix "s" (English plural) can give a hint that it stores multiple values.
def records = api.find(...) for (record in records) { //do something with with record.attribute1 ... }
Groovy Functions
The general rule is to make the first letter lowercase. Even though Groovy, compared to Java, allows the first letter in uppercase, it is recommended to follow the Java convention.
Example: getCostPrice()
Data gathering functions should use a common prefix. This will significantly help when identifying performance problems. Remember that each function should do only one thing at a time: either gather data or manipulate the data somehow; do not mix these two.
Proposal:
- Functions querying PriceBuilder (= calling functions api.find() or api.findLookupTableValues()) use the prefix find, e.g. findSalesOrgs().
- Functions querying PriceAnalyzer (= calling executeQuery or executeSqlQuery)) use the prefix load, e.g. loadTransactions().