Page Comparison

1. CRITICAL: Copy pasting the code is not allowed, functions should be

...

1. used for the shared functionality

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

3. always use curly brackets for if, for, while

...

1. , e.g.:

   Code Block
   if (isCondition) { return null }

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

3. Follow the Recommended Logic Structure

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

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

6. Avoid api.local, api.global where possible

...

1. , for small amount of data, use a dedicated element

...

1. - this will help you to trace the logic more easily

...

1. . Big data can cause a slow down. Forbidden to use in functions (except special meaning like caching).-

2. Use

...

1. field names in filters or use api.

...

1. namedEntities(

...

1. ) if possible

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

...

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

...

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

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

3. 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.

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

5. 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)

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

7. 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)

8. 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.

9. If casting is needed e.g. ?.toBigDecimal() for amounts

...

1. , do this on the first occurrence of the variable

2. 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.

3. 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

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

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

...

1. Initialize Map directly

...

1. . E.g. instead of

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

   directly use (and following auto-format):

...

1. Code Block

...

1. def map = [:]

...

1. map["key1"] = "value1"

...

...

1. map["key2"] = "value2"

...

...

1. map["key3"] = "value3"

...

2. Analogically, initialize List directly

...

...

1. . E.g. instead of

   Code Block
   def map = [:]

...

1. map["key1"] = "value1"

...

1. map["key2"] = "value2"

...

1. map["key3"] = "value3"

   directly use (and following auto-format):

...

1. Code Block

...

1. def

...

1. map = [:]

...

1. map["key1"] = "value1"

...

...

1. map["key2"] = "value2"

...

1. map["key3"] =

...

1. "value3"

...

2. Split suuuuperlooooong lines

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