Coding Style

CRITICAL: Copy pasting the code is not allowed, functions should be used for the shared functionality

All code reflects the auto-format, see Unified Code Style and How to Auto Format;

always use curly brackets for if, for, while , e.g.:

if (isCondition) {
  return null
}

Reformatting of big amount of old code should be done within a separate commit

Follow the Recommended Logic Structure

Use out.SomeElement prior to (deprecated) api.getElement("SomeElement")

Use input.SomeInputName prior to (deprecated) api.input("SomeInputName")

Avoid api.local, api.global where possible, for small amount of data, use a dedicated element - this will help you to trace the logic more easily. Big data can cause a slow down. Forbidden to use in functions (except special meaning like caching).-

Use field names in filters or use api.namedEntities() if possible

Use real data type when declaring the variable instead of def. Mandatory use in functions - both parameters and the return type!

Prevent api.isSyntaxCheck Issues by having AbortSyntaxCheck element in the logic

Keep methods simple. More smaller methods is better than a big one

Use https://pricefx.atlassian.net/wiki/spaces/DEV/pages/2946629934/Input+Builders - mandatory for configurators and header logics, but recommended also for ordinary logics

Smartly use of @Field constants (no use for fields, table names, configurator names in customer projects). Mandatory use for important values used in conditions or in accelerators.

Use api.findLookupTableValues("TableName") instead of api.find("MLTVx", ...)

Use one approach for adding item to the list, do not mix the approaches. Recommendation is to use List << value prior to List.add(value)

Use the same approach for accessing List item, do not mix the approaches. Recommendation is to use List[index] prior to List.getAt(index)

Use the same approach for accessing Map values, do not mix approaches. Recommendation is to use Map.key prior to Map[key] or Map.get(key)

BigDecimal should be the commonly used data type for amount or percentage variables (never use floats for amounts!). Use BigDecimal constants (e.g. 0.0 instead of 0) so you can rely on BigDecimal.

If casting is needed e.g. ?.toBigDecimal() for amounts, do this on the first occurrence of the variable

Use closures (collect, collectEntries, each, eachWithIndex, max, min, inject, sort, etc.) whenever applicable. Note: utilize use of sortBy parameter in api.find() prior to sort() closure for a better performance.

Use "find" (resp. "query") prefix for the name of a function that is querying PB tables (resp. PA datasources/datamarts) Do not mix data querying and calculation in the functions

Use the method library alias when calling several Groovy library function in the element or function: def CurrencyUtils = libs.MainLib.CurrencyUtils

PERFORMANCE: avoid returning big data in an element. Remember: in Groovy, the expression on the last line is the value returned!

Initialize Map directly. E.g. instead of

def map = [:]
map["key1"] = "value1"
map["key2"] = "value2"
map["key3"] = "value3"

directly use (and following auto-format):

def map = [:]
map["key1"] = "value1"
map["key2"] = "value2"
map["key3"] = "value3"

Analogically, initialize List directly. E.g. instead of

def map = [:]
map["key1"] = "value1"
map["key2"] = "value2"
map["key3"] = "value3"

directly use (and following auto-format):

def map = [:]
map["key1"] = "value1"
map["key2"] = "value2"
map["key3"] = "value3"

Split suuuuperlooooong lines

Dot not commit commented code, api.log and api.trace in GIT