Personal Insights
Clean ABAP – an example, simple refactoring. And a call for assistance to AdT
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-exporting)
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-notation-and-prefixes )
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
Yes, it would be nice to have a pretty printer configuration that would lead to the formatting in your third example (4 lines instead 8) :
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.)
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 Edo von Glan there are a few plugins out there by the one and only Łukasz Pęgiel that can help here a bit ... chek 'em out! (links refer to the corresponding twitter posts)
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 🎤🐛
Thanks for the link to Łukasz Pęgiels GitHub - fidley/ABAPQuickFix: ABAP Quick Fix .
Looks good - I will check it out.
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:
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:
Thanks,
Alejandro Cordero.
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
into
unless the type of e_that is not generic. That would be cool!
Yeas, I have stumbled about such non-obvious generic typing a few times.
Like: If my method is defined like this:
...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:
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.