General

Where ever identifier is required (uniqueName, name, etc.) field is used, 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 underscore character "_", for example as ABC_Class instead of ABCClass.

Labels are typically copy of the uniqueName/name and the words are split using spaces.

Here are some commonly used conventions for the identifier suffixes:

...

The suffixes can be combined

Logic names

Follow general rule with using a first letter in uppercase.

Example: DefaultLogic, Pricelist, Main, DefaultQuoteLogic

For the following logic types, there is a recommendation for a 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.

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:

Note: 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

...

Follow general rule with using a first capital letter. The library element names should have a suffix "Utils" (e.g. RoundingUtils, CacheUtils, DatamartUtils).

The reason for a first letter is that element is implemented as a Groovy class and therefore referring to element's methods from Groovy is done as SomeElement.callSomeMethod(). For this syntax the method auto-completion will work in Studio, since IDEA will understand it as a static call of a method (even though it is in reality not a static call but an instance call on a binded object).

Another reason for a capital letter is to have the possibility to refer to previous elements

In order to make auto-completion working in Studio or to be able to run TDD4C without marking the folders as source in Studio, it is recommended to use always a different element name that is unique within the project. Also element name "Filter" is not recommended, since the auto-completion collides with standard Filter object used frequently by the logics.

Example: NewMargin, SalesPrice

Element Labels

Element names should ideally be matching the element name where spaces are used and each word starts with a capital letter which is 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 of time. Therefore the labels should not be referred in the logic, element name or attribute should be used.

Groovy variables

Follow general rule with using a first letter in lowercase. Even though Groovy, compared to Java, allows first letter in uppercase, following Java convention is recommended.

Example: newMargin, salesPrice

If the variable stores a list of values, then the suffix "s" (English plural) can give a hint it is storing multiple values.

	def records = api.find(...)

    for (record in records) {
		//do something with with record.attribute1
		...
	}

Groovy methods

Follow general rule with using a first letter in lowercase. Even though Groovy, compared to Java, allows first letter in uppercase, following Java convention is recommended.

Example: getCostPrice()

DF/DS/DM fields

Follow general rule with using a capital first letter.

TODO: should be changed to lower case due to better use in SQL queries?

Example: NewMargin, SalesPriceshould 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.

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.

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:

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.