Clean ABAP - an example, simple refactoring. And a call for assistance to AdT

[joachimrees1]

I try to explore and embrace cleanABAP and you might know that I have started with the very easy "get rid of empty lines".

There are other things I can do, in regards to make the code denser and thus cleaner, easier to understand, so I see more code with one glace and need less scrolling. -> Optimize for reading.

Here is an example:

I might start with this (some old code I find and want to clean)

        lref_srv_wt->to_create_move_hu(

          EXPORTING

            iv_commit_work = abap_true

            iv_wait        = abap_true

            it_create_hu   = lt_create_hu

          IMPORTING

            ev_tanum       = DATA(lv_tanum) 

            ).

1. Remove unneeded line breaks:

        lref_srv_wt->to_create_move_hu( EXPORTING iv_commit_work = abap_true

            iv_wait        = abap_true

            it_create_hu   = lt_create_hu

          IMPORTING ev_tanum       = DATA(lv_tanum) ).

2. Indent, to align it:

        lref_srv_wt->to_create_move_hu( EXPORTING iv_commit_work = abap_true

                                                  iv_wait        = abap_true

                                                  it_create_hu   = lt_create_hu

                                        IMPORTING ev_tanum       = DATA(lv_tanum) ).

 

( I actually had to look up https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#align-parameters for making sure I am done here, as I had the temptation to also remove unneeded whitespace, braking the alignment on = but making my code denser.

Like so:

	lref_srv_wt->to_create_move_hu( EXPORTING iv_commit_work = abap_true

                                              iv_wait = abap_true

                                              it_create_hu = lt_create_hu

                                    IMPORTING ev_tanum = DATA(lv_tanum) ).	

 

Further [but more complicated, as in: there are prerequisites to it] things I could do:

[If had control over the method to_create_move_hu:]
- change the exporting parameter to a returning one, thus:
-> saving another line
-> being able to remove the then uneeded EXPORTING (https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#omit-the-optional-keyword-expor...)

lv_tanum = lref_srv_wt->to_create_move_hu( iv_commit_work = abap_true

                                           iv_wait        = abap_true

                                           it_create_hu   = lt_create_hu ). 

[ If I had control over the rules I agreed to when joining the project] I also could get rid of Hungarian notation / prefixes ( https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#avoid-encodings-esp-hungarian-n... )

tanum = srv_wt->to_create_move_hu( commit_work = abap_true

                                   wait        = abap_true

                                   create_hu   = create_hu ). 

It does look a lot better, doesn't it?

 

So what I did here, is give an example of how I do apply some rules of cleanAbap.

But my original thought was another one, and here I would appreciate some help: Steps 1 and 2 are not hard to do at all, they are really easy. They are so easy that I feel like I should not have to do them by hand: It should be one click/keystroke/quick-assist.
Is there a way AdT can help me do that? (Ref. my question: https://answers.sap.com/questions/13558374/adt-code-formater-to-help-towards-cleanabap-empty.html )

Thanks!
Joachim

[vonglan]

Yes, it would be nice to have a pretty printer configuration that would lead to the formatting in your third example (4 lines instead 😎 :

        lref_srv_wt->to_create_move_hu( EXPORTING iv_commit_work = abap_true

                                                  iv_wait        = abap_true

                                                  it_create_hu   = lt_create_hu

                                        IMPORTING ev_tanum       = DATA(lv_tanum) ).

My personal approach with regard to code formatting has evolved from "keep everything nice all the time" to "rely on the pretty printer mostly, and keep everything reasonably nice".

Because time and again, when I use the AdT renaming feature, I notice that it breaks the = etc. alignment.

The time to make everything nice manually again, is just not worth it. (Well, maybe if you are developing standard software, but not at a typical SAP customer.)

 

[wridgeu]

Great and concise blog post and I love seeing examples with, which I assume to be, EWM code snippets 😁

There are a few plugins out there to improve some of the ADT features. Not sure however if there is some "extended" or "advanced" prettier configuration possible yet. I'd love to see that in the future though 😅

Regarding the last point from vonglan there are a few plugins out there by the one and only 28f4b37a40894f18a22abc696b8154f4 that can help here a bit ... chek 'em out! (links refer to the corresponding twitter posts)

• https://twitter.com/abapblog/status/1281511848257490948?s=20
• https://twitter.com/abapblog/status/1382401228433465347?s=20
• https://twitter.com/abapblog/status/1272255653982150660?s=20

Love seeing other devs taking care of some old code or, even more important, new code and adapt it to #CleanABAP ... you gotta start somewhere!

BR,

Marco 🎤🐛

[ACORDERO]

Nice blog! Thanks for sharing your example.

I would love to know a little bit more about your context and ask you a few questions, I bet your answers will help others.

Your example is related to Formatting style which is a very tricky subject among developers because formatting style is very subjective, each developer may like to see the code formatted in a different way and get into an agreement can be challenging. It seems to be that your applying the CleanABAP guide (which is very good), so my questions for this point are:

• How was the conversation with the team where you decided to adopt and apply the CleanABAP guide? Were they willing to adopt it without any arguments?


• Was there anything in the CleanABAP guide that you had to change because they didn't like it?

Then, you said that you got this example because you have "some old code I find and want to clean".

It looks like you were making a change to an existing code (I assume there was a business reason) and then you followed the Boy Scout rule, so you took the extra time to change existing code to make it cleaner (really nice), so I do have some questions about this:

• Because you're making manual changes (and this is why you are asking for an automated solution), you could introduce new bugs in your code. How and why are you taking this risk?


• Do you have automated test which cover your changes so you don't have to worry about making mistakes (because they will be flagged)? (I have never seen an automated test in ABAP in a real project, yes, very sad)

Thanks,
Alejandro Cordero.

 

[matt]

IMPORTING a single value does not transform 1:1 to a functional method. For that you need a RECEIVING parameter.

The point is that an IMPORTING parameter may be defined (and often is) in the method with a generic type. E.g. STANDARD TABLE.

So I wouldn't look for a transformation of

my_method( EXPORTING i_this = something

           IMPORTING e_that = something_else ).

into

something_else = my_method( something ).

unless the type of e_that is not generic. That would be cool!

 

[joachimrees1]

Yeas, I have stumbled about such non-obvious generic typing a few times.

Like: If my method is defined like this:

types: ty_product_table type table of mara.

Methods: my_method exporting materials type ty_product_table .

...I feel like it's easy to just change to exporting to returning, only to be told by syntax check that this is not possible with generic types.

What I usually do in those cases is change the type to:

types: ty_product_table type table of mara with non-unique default key.

Methods: my_method returning value(materials) type ty_product_table .

[matt]

It's not always possible to make the parameter non-generic, and if you're writing some kind of generic code it can make real sense.

But for those purposes, you can use TYPE REF TO DATA as the returning parameter.

[vonglan]

Thanks for the link to 28f4b37a40894f18a22abc696b8154f4s  GitHub - fidley/ABAPQuickFix: ABAP Quick Fix .

Looks good - I will check it out.

[franois_henrotte]

you can also pass an OO interface as parameter then access to its public attributes (directly or through a getter)