Formatting issue with structured types including a structured type
I hope it's not a config option I'm missing, but this (already ABAP cleaner formatted code):
TYPES:
BEGIN OF ty_conf_out_posnr.
INCLUDE TYPE conf_out AS conf_out.
TYPES: items TYPE string_t,
END OF ty_conf_out_posnr.
Should be this:
TYPES:
BEGIN OF ty_conf_out_posnr.
INCLUDE TYPE conf_out AS conf_out.
TYPES: items TYPE string_t,
END OF ty_conf_out_posnr.
Writing the below code will revert back to the the upper version when I run ABAP cleaner (or actually something worse, it puts the END OF... statement on row 0).
My config: ECC.zip
This is the result for my profile:
TYPES: BEGIN OF ty_conf_out_posnr.
INCLUDE TYPE conf_out AS conf_out.
TYPES: items TYPE string_t,
END OF ty_conf_out_posnr.
Maybe it'll be helpful for Jörg-Michael if you provide your profile to reproduce the problem. 🙂
I mentioned this same behavior as part of what I saw as a larger issue as # 3 here. That was in the context of different behavior between abap-cleaner and the standard formatter/pretty printer, but I do still find this to be an issue overall.
I've updated my OP with my configuration file.
Hi hansdampfinger666,
this is usually handled by the cleanup rule "Align declarations" which, however, is deactivated in your profile. Actually, if the input is …
TYPES:
BEGIN OF ty_conf_out_posnr.
INCLUDE TYPE conf_out AS conf_out.
TYPES: items TYPE string_t,
END OF ty_conf_out_posnr.
… PrettyPrinter isn't happy with it, either, but would result in:
TYPES:
BEGIN OF ty_conf_out_posnr.
INCLUDE TYPE conf_out AS conf_out.
TYPES: items TYPE string_t,
END OF ty_conf_out_posnr.
If you feed that into ABAP cleaner, you get:
TYPES:
BEGIN OF ty_conf_out_posnr.
INCLUDE TYPE conf_out AS conf_out.
TYPES: items TYPE string_t,
END OF ty_conf_out_posnr.
So from my perspective, the problem is only that ABAP cleaner shouldn't move the INCLUDE line to the left.
Another idea would be to (manually) move the second TYPES: to line end and activate "Align declarations", because in the most recent ABAP cleaner release, "Align declarations" also accepts this style:
TYPES:
BEGIN OF ty_conf_out_posnr.
INCLUDE TYPE conf_out AS conf_out. TYPES:
items TYPE string_t,
END OF ty_conf_out_posnr.
Kind regards, Jörg-Michael
Hi hansdampfinger666,
I now modified the "Indent lines" rule to indent INCLUDE lines like PrettyPrinter would do it. Therefore, with the next ABAP cleaner release, all of the following cases will be kept unchanged by "Indent lines" (note that for PrettyPrinter, it is relevant whether or not the TYPES statement before an INCLUDE is a chain):
TYPES: BEGIN OF ty_s_any,
comp1 TYPE i.
INCLUDE TYPE ty_s_other AS other.
INCLUDE TYPE ty_s_third.
TYPES: comp2 TYPE string,
END OF ty_s_any.
TYPES:
BEGIN OF ty_s_any.
INCLUDE TYPE ty_s_other AS other.
INCLUDE TYPE ty_s_third.
TYPES:
comp TYPE string,
END OF ty_s_any.
TYPES BEGIN OF ty_s_any.
TYPES comp1 TYPE i.
INCLUDE TYPE ty_s_other AS other.
TYPES comp2 TYPE string.
TYPES END OF ty_s_any.
This layout can be overridden by the "Align declarations" cleanup rule, but if that's deactivated as in your profile, you will at least not get a conflict with PrettyPrinter.
Even with that, this style …
TYPES:
BEGIN OF ty_conf_out_posnr.
INCLUDE TYPE conf_out AS conf_out.
TYPES: items TYPE string_t,
END OF ty_conf_out_posnr.
… is still not supported, because PrettyPrinter would change the indentation of the second TYPES: as well. I do, of course, understand the idea of this, and like I said, an alternative may be to put the second "TYPES:" at the end of the previous line (ABAP cleaner would keep that, but can't automate this as of now). It's really regrettable that INCLUDE can't be simply be part of a TYPES: chain; but I guess this is not possible, because you couldn't distinguish it from a component by the name of "include".
Kind regards, Jörg-Michael
Okay, thanks for looking into this @jmgrassau!
Hi hansdampfinger666,
thanks again for opening this issue – this should now be fixed (as described above) with version 1.16.2, which was just released.
Kind regards, Jörg-Michael
Thank you so much @jmgrassau!