A RETURNING parameter must be fully typed

[lucasborin]

Based on the Prefer RETURNING to EXPORTING, I was wondering to automate it in the code pal, but I faced one pretty interesting false-positive and I would like to ask for your perspective here.

If I find:

CLASS local DEFINITION.
  PUBLIC SECTION.
    TYPES: BEGIN OF ty_result,
             partner TYPE string,
             adrnr   TYPE string,
           END OF ty_result.

    TYPES tt_result TYPE TABLE OF ty_result.

    METHODS get EXPORTING result TYPE tt_result.

ENDCLASS.

or even:

    METHODS get EXPORTING VALUE(result) TYPE tt_result.

I would expect we could convert the EXPORTING to RETURNING as mentioned in the style guide. However, If you do so, you will get the following syntax error:

A RETURNING parameter must be fully typed.

It looks like the developers are using the EXPORTING to 'bypass' it.

So, in your perspective, is it better to keep the EXPORTING in such a case? Or, should the developer create a new DDIC structure?

Ref: https://github.com/SAP/code-pal-for-abap/issues/417 and https://github.com/SAP/code-pal-for-abap/pull/418

[larshp]

well, you can look at https://docs.abapopenchecks.org/checks/44/ and https://rules.abaplint.org/prefer_returning_to_exporting/ for inspiration, it tries to determine when the type is generic

IMHO, always prefer RETURNING when possible

[shafiq2601]

We can use “WITH EMPTY KEY” while declaring, for fully specifying table types.

Types: tt_result TYPE TABLE OF ty_result WITH EMPTY KEY.

On Tue, 22 Jun 2021 at 10:31 AM, Lars Hvam @.***> wrote:

well, you can look at https://docs.abapopenchecks.org/checks/44/ and https://rules.abaplint.org/prefer_returning_to_exporting/ for inspiration, it tries to determine when the type is generic

IMHO, always prefer RETURNING when possible

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SAP/styleguides/issues/218#issuecomment-865563085, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJIONXSBVY2K6C5KDW2VECLTUAKMJANCNFSM47CI34OA .

[pokrakam]

My first reaction was that requiring fully typed parameter is a good thing, all we need is a WITH EMPTY KEY as suggested, and therefore this should be enforced. But on second thoughts this may be a valid use case, and there are many cases of generic parameters, CL_SALV_TABLE=>FACTORY( ) comes to mind. Then again all strict typing can be bypassed with TYPE REF TO DATA Hmm...

[lucasborin]

Oh, perfect. The developer can define the table keys (default, empty, non-unique, etc) to solve it. Thank you all.