Coding Style

CRITICAL: Copy pasting the code is not allowed, functions should be used for to share 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, otherwise it is almost impossible to validate the merge request.
Follow the Recommended Logic Structure. Try to leep all input elements in the beginning of the logic.
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. Should not be used in functions (except e.g. 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 functions simple. More smaller methods is better than a big one
Where to place functions? 1. in the element - if used only once 2. in the Library element - if used only within the logic 3. in Groovy Library - if used between logics.
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 repeatedly used constant Strings or used 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)(unless you night nullsafe operator)
Use the same approach for accessing List item, do not mix the approaches. Recommendation is to use List[index] prior to List.getAt(index)(unless you night nullsafe operator)
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, find, findAll, first, last, 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 library element 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 = [
  key1: "value1"
  key2: "value2"
  key3: "value3"
]

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

def list = []
list << "value1"
list << "value2"
list << "value3"

directly use (and following auto-format):

def map = [
    "value1",
    "value2",
    "value3"
]

Split suuuuperlooooong lines. If the function has many parameters, put each parameter on a separate line.
Dot not commit commented code, api.log and api.trace in GIT
Resolve the TODOs