code pal for ABAP > Avoid DEFAULT KEY
Default keys are often only added to get the newer functional statements working. The keys themselves in fact are usually superfluous and waste resources for nothing. They can even lead to obscure mistakes because they ignore numeric data types. The
SORT
andDELETE ADJACENT
statements without explicit field list will resort to the primary key of the internal table, which in case of usage ofDEFAULT KEY
can lead to very unexpected results when having e.g. numeric fields as component of the key, in particular in combination withREAD TABLE ... BINARY
etc.
Source: Clean ABAP - Avoid DEFAULT KEY.
Therefore, this check searches for the internal table definitions which forces the use of the default key.
Either specify the key components explicitly
DATA itab1 TYPE STANDARD TABLE OF row_type WITH NON-UNIQUE KEY comp1 comp2.or resort to
EMPTY KEY
if you don't need a key at all.DATA itab1 TYPE STANDARD TABLE OF row_type WITH EMPTY KEY.
Source: Clean ABAP - Avoid DEFAULT KEY.
In exceptional cases, you can suppress this finding by using the pseudo comment "#EC DEFAULT_KEY
which has to be placed after the declaration:
CLASS-DATA itab1 TYPE STANDARD TABLE OF row_type WITH DEFAULT KEY. "#EC DEFAULT_KEY
DATA itab1 TYPE STANDARD TABLE OF row_type WITH DEFAULT KEY. "#EC DEFAULT_KEY
TYPES: BEGIN OF type1, ' )
non_unique TYPE STANDARD TABLE OF row_type WITH NON-UNIQUE KEY object,
default_key TYPE STANDARD TABLE OF row_type WITH DEFAULT KEY, "#EC DEFAULT_KEY'
empty_key TYPE STANDARD TABLE OF row_type WITH EMPTY KEY,
END OF type1.
Before the check:
DATA itab1 TYPE STANDARD TABLE OF row_type WITH DEFAULT KEY.
After the check:
DATA itab1 TYPE STANDARD TABLE OF row_type WITH NON-UNIQUE KEY comp1 comp2.
DATA itab1 TYPE STANDARD TABLE OF row_type WITH EMPTY KEY.