Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents
maxLevel1

General

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:

...

The suffixes can be combined. 

Logic Names

The general rule is to make the first letter uppercase

Example: DefaultLogic, Pricelist, Main, DefaultQuoteLogic

For the following logic types, there is a recommended prefix/suffixNaming 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.

Table of Contents
minLevel1
maxLevel7

Logic Names

Logic names should be written in CamelCase, with the first letter capitalized, for example:

  • PriceGrid

  • CustomerPriceList

Preferably, if the logic is tied to a certain object type, it should start with the type code as a prefix:

Logic type

Formula Nature

Prefix

Suffix

Example

Agreements and Promotions Header

contractHeader

AP_

AP_Header

Agreements and Promotions Line Item

contract

AP_

AP_LineItem

Calculation Flow

calculationFlow

CF_


CF_

DailyCalculation

RebateRecords

Calculated Field Set

null (default)

CFS_


CFS_ProductEnrichment

Dataload

Contracts

CT_

CT_DefaultContractLogic

Configurator

null (default)

Configurator

SampleConfigurator

Data Load

paDataLoad

DL_


DL

_LoadFromPX

_ProductCost

Distributed Data Load

distPACalc

DLD_

DLD_RebateAllocation

Dashboard

null (default)

DB_

DB_Waterfall

Price List

null (default)

PL_

PL_National

Live Price Grid

null (default)

PG_

PG_Computers

Quotes

null (default)

Q_

Q_DefaultQuoteLogic

Rebates Agreements Header

rebateAgreementHeader

RM_

RM_Header

Rebate Agreements Line Item

rebateAgreement

RM_

RM_Rebate

Groovy Library

library


Lib

SharedLib

MonitoringLib

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: 

Jira Legacy
serverSystem JIRA
serverId0e65890b-f559-36c3-b4f7-807e5b0df1a0
keyPM-284

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.

Code Block
languagegroovy
	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 function should only do one thing at a time = either gather data or manipulate the data somehow, not mix.

Proposal:

  1. Functions that are querying Price Builder (= calling functions api.find() or api.findLookupTableValues()) use prefix "find" e.g. findSalesOrgs().
  2. Functions that are querying Price Analyzer (= calling executeQuery or executeSqlQuery)) use prefix "load" e.g. loadTransactions().

DF/DS/DM Fields

The general rule is to make the first letter in uppercase.

Note: In SQL queries the fields are referred to in lowercase.

Example: NewMargin, SalesPriceNote: In the long term, we would like the logics of the same Formula Nature to be stored in a subfolder. Default Formula Nature should be deprecated, so there will be no need for prefixes.

Element Names

Element names should be written in CamelCase, with the first letter capitalized, for example:

  • InvoicePrice

  • CustomerPrice

  • ResultPrice

  • MarginNew

Exception: This rule is not valid for logics serving as a custom HTTP API where the letter case of JSON fields needs to be matching the API interface specification.

The element name should be different to classes from java.lang or java.util because IDEA can then show more false alert inspections. So avoid element names like Map, List, etc.

Info

During deployment, the Groovy logic element scripts get compiled into classes. During logic execution, the logic engine instantiates singleton objects from those classes. These objects then get bound to variables with the same name as the elements. Thus, to call a method callMethod()that is located inside an element ElementName:

ElementName.callMethod()

Pricefx Studio will make IntelliJ interpret this as a static call – even though it is not – and that will make the auto-completion work.

Unique Element Names Within Projects

Element names should also be unique within the entire project – across all logics and classes from java.lang or java.util packages. This is to enable the auto-completion and unit testing with TDD4C. Examples of too common names causing issues:

  • Library

  • Lib

  • Utils

  • Filter

  • Product

  • Customer

  • etc.

Info

When running the logic locally, the element classes will belong to the default pages. The JVM requires classes within the same packages to be unique, so this will make the local compilation fail.

Library Elements

Groovy library element names should be suffixed with Utils, for example:

  • RoundingUtils

  • CacheUtils

  • DatamartUtils

  • DateUtils

  • MathUtils

Common Patterns

Across logics and entire projects, some patterns of element behavior tend to emerge. For these elements, here are some suggested naming conventions:

Suffix

For

Example Element Name

Example Label

Example Value

Diff

Elements that represent a difference, i.e. a result of a subtraction

VolumeDiff

Volume ∆

234 litres

Abs

Elements that represent an amount of money, in absolute terms.

MarginAbs

Margin EUR

Margin $

Margin €

34

$23

€34

Pct

Elements that represent a quotient. These elements are typically formatted as percentages.

MarginPct

Margin %

0.45

Note

Despite the naming convention, the value should be represented as fraction, i.e. it should not be multiplied by 100.

s

Elements that represent a collection.

PX_Records

Element Labels

Will probably get deprecated. Use the label translations instead.

Label Translations

Labels in the default language should be identical to the element names, but with the words separated by spaces. Some words can be replaced by symbols, for example:

  • SalesPrice – Sales Price

  • MarginPct – Margin %

  • Margin Abs – Margin €

Element labels are optional for those elements that are hidden for the end users.

Data Source / Datamart Field Names

The general rule is to make their first letter in uppercase. Examples:

  • MarginNew

  • SalesPrice

Note: In PA SQL queries the columns are retrieved in lowercase due to how Postgres works.