QuickFix to inline PERFORM statements

[kevinholtkamp]

When trying to refactor old code, one thing I often do is inline old PERFORM statements, and afterwards often to extract a method from the inlined code.

Would it be possible for a quick fix to inline a PERFORM statement and maybe even to extract a method afterwards and thus effectively replace a PERFORM with a method call?

I think at least for the first part, global variables should not be an issue, because when the FORM is in scope, all global variables used in the FORM should be in scope from the caller aswell. Parameters would need to be renamed in case of duplicates.

[fidley]

Hi @kevinholtkamp ,

thanks for the idea. I can try to support you here in this "nice" work of refactoring old code. But I'm not sure this can be handled easily, as the plugin works only on front-end of Eclipse, reading current open editor as a plain text and then replacing the selected code via regex or manual adaptations.

I can easily catch the beginning and end of the FORM statement. I could replace it in its place to a method implementation, but to add method definition, or even class definition this could be more hard. If you use includes in the program, then almost unrealistic. Same with replacing perform with method call, as it can be used in other includes or even programs.

I guess such conversion from program to class/es would need to be done on back-end side, where you can find all where used places and you can read the code with all includes (using scan abap statement). This could be a nice project, but more planning and clear spec would be needed, means the logic that could be applied. The base could be the manual way you do in your work, if you could share step by step procedure you do, we may think about how to implement this in Quick Fixes.

Cheers Łukasz

[kevinholtkamp]

Hi @fidley , thanks for the response!

To the part about needing files to be opened: Could the plugin call for Eclipse to open any file needed that is not open yet?

Regarding the refactoring itself: if the whole thing is too complicated, it would be enough to just inline the PERFORM, because you can then use the regular refactorings afterwards.

My thinking is that when you use PERFORM, the form must be in the current scope, thus everything used inside the FORM will be in scope from the callers perspective aswell. In that case, inlining the PERFORM and renaming the parameters would suffice without any further analysis. Example:

FORM do_stuff USING x TYPE test y TYPE test z TYPE test.
  global_var = x + y + z.
ENDFORM.

METHOD oo.
  PERFORM do_stuff USING a b c.
ENDMETHOD.

Since do_stuff is in scope inside the method, global_var should be aswell, thus you could just replace the PERFORM with the code inside the form and replace the parameters, so that it looks like this:

"Could be deleted if not used anywhere else
"FORM do_stuff USING x TYPE test y TYPE test z TYPE test.
"  global_var = x + y + z.
"ENDFORM.

METHOD oo.
  global_var = a + b + c.
ENDMETHOD.

Am I correct in my assumptions?

[fidley]

Theoretically I can navigate (open) the definition of the FORM, but this would not work correctly during the Quick Fix processing, as I need to provide to Eclipse the information about exact proposal of replacement, when you use Ctrl+1 key combination. I guess the navigation may not work then, and if it would work, then the context of quick fix would be lost or some other odd behaviour of the UI would happen.

The only way I see it could work, is to do such calculations in the backend and so far I kept this plugin out of the need of installing anything in ABAP system.

I will leave this open for now, and I'll think if there is a chance for me to build a nice backend solution for this.