Feature-Request: Extract/Refactoring Form-Routines

[Former Member]

Hello,

could you please think about extending the extract-refactoring to form-routines?

We would like to extract code from a form-routine into a new static class-method to *begin* refactoring legacy code as described in "Working effectively with legacy code"...

Currently it's shock-and-awe:

awe: we can easily extract code and it's working great!

shock: we are limited to classes and cannot refactor the existing function-group codebase....

Great work so far!

Cheers,

Kai

[michael_gutfleisch]

Hi Kai,

do you want to move the the form routine(s) to local or global classes?

What should happen with global variables which are used inside the form routine(s)?

What if you move a second form routine? Should it be moved to a new class or the same as the first form routine?

What do think about the transformation of parameters? (parameters of form routines cannot always be mapped correctly to parameters of methods?

What statements which are not allowed inside OO-context?

Regards,

Michael

[Former Member]

do you want to move the the form routine(s) to local or global classes?

Ultimately I want to decide but for a start I could not care less, local classes should be perfectly fine for this kind of refactoring.

What should happen with global variables which are used inside the form routine(s)?

Suggest as changing Parameters?

What if you move a second form routine? Should it be moved to a new class or the same as the first form routine?

Let me decide but recommend the previously used class.

What do think about the transformation of parameters? (parameters of form routines cannot always be mapped correctly to parameters of methods?

Out of interest. which cases would that be?

Generally: do not handle edge cases and abort with a readable message. Don't try to handle the ugly 5%.

What statements which are not allowed inside OO-context?

see above.

thanks for your comments. cheers

[Florian]

Hi Kai,

why aren't you developing your things via an class and use all the awesome features with aie?

In my opinion there is no valid reason why someone need to use formroutines and yes, I know that it ends in some more work because of not having program globals

~Florian

[Former Member]

I am trapped in a brownfield of legacy form-routines and try to refactor stuff into classes and you're asking me why I prefer form routines

I don't. I want to get rid of them but I need refactoring assistance or I will shoot myself.

[former_member234884]

Hi Kay,

I am looking for a solution too. I have googled a lot for something like a conversion program. But nobody has created one. I would be happy too if there is something what can move selected forms to ONE local class converting globals to member attributes.

Best regards

Andreas

[former_member234884]

Hi all,

any news on this? Even SAP could use this to clean some corners.

Best regards

Andreas

[Former Member]

+1

[michael_gutfleisch]

Hi Kai and Andreas,

I understand the wish to have an automated conversion from form routines to classes and methods, but there are mainly two reasons why we will most likely not provide it:

First, it will be a very huge effort to build it even when we skip the ugly 20%. And we can't skip them because than we will get the complaints because those edge case don't work out smoothly. Probably not from you but from other developers.

In general, a refactoring is defied as a code transformation that does preserve the behavior of the software. And that's what many people will expect if SAP provides automated refactorings. And I#m pretty sure that we cannot fulfill this expectation in many cases (you call the edge cases).

Second, I think such a transformation will end up in a mess at least from a design perspective. Because a collection of form routines is a completely different design than having objects with well defined responsibilities interacting with each other.

By the way, creating a new class manually, moving the content of a form into a new method and finally calling the new method inside the form is not that much effort... compared to the manual rework that I expect even if an automated "extract method from form" would do the first shot.

Best regards,

Michael

[former_member234884]

Hi Michael,

many thanks for your reply.  I understand too that there is no way to make a perfect tool for this but I have done this many many times and it is very time consuming to change the interfaces. After this the real work can begin:

- Separating the routines to different classes.

- Moving Parameters to attributes

- and so on.

But for this I can use already the existing functionality of Eclipse.

For your information, I develop since 8/99 in ABAP before this I have started in Ansi-C since 1984. I develop very huge single programs (up to 200 man days or more) with many classes and and Object creations  (not only replacing function groups by classes). I am a real OO hardcore developer for a long time.

So I will state out even a 80% solution will help much!

And by the way: On my Macs the ADT solution is not perfect too (it crashes, it hangs, the inplace SAP GUI Java does not work probably) But I love it 😉

Best regards

Andreas

[Former Member]

I understand your concerns but we don't need automated refactoring.

I really need some kind of *assisted* refactoring, where it is totally acceptable to assist in most common refactorings but do not fully automate the whole task...

Having 80% assistance and manually cope with the remaining 20% is soooo much better than doing the whole load.

[Florian]

Hi Kai,

question between. Why do you refactor into form-routines?

I can understand your point of view, but today while getting my hand on old reports and such things I refactor always into methods. Most of the times static methods, but that doesn't matter, all the help of ADT is right now with me like extract to new methods...

So I'm not really sure, why we are discuss this feature...

There are other features missing and I won't name it in this discussion, but I'm sure a lot of developers have more pain because of other features.

~Florian

[former_member234884]

Hi Florian,

I think you that you misunderstood the reason for this discussion. Kai and myself like to refactor/transform OLD FORMS TO NEW METHODS! Nothing else!

Best regards

Andreas

[Former Member]

Basically what Andreas said.

Are you saying your ADT offers to extract source from existing forms or whole forms into class methods?

[Florian]

Mhh.. yes, your right I thought you want to refactor form-routines to form-routines, but my point of view doesn't change at all. But thanks for clarifying it.

~Florian

[Florian]

Hi Kai,

no it doesn't. I do it step by step. I'm pretty sure the big problems are generating the interface. You know, most of the inserted code somewhere between form-routines is using global parameters and there are the problems.

Don't shoot me, but I really do not see your problem here.

What I understand is that you have formroutines and want to extract those into static-methods...

Are you going to do it for all you ever coded in your whole system?

I think that is a work you will never finish and a automatic refactoring-tool will end in a lot of extra work to find the spots, why code is working in different ways.

My way is every single line of code I have to touch during the year is transformed to OO, no matter if static or instance.

At that moment I have to touch the code I build an class and put the "old" form-coding into the class and build an interface.

Now I got all solutions available and can build my function thousand lines long and afterwards mark some parts and refactor it in smaller reusable methods.

That's it.

Sorry that I repeat myself, but I really do not see a need for such a function. Maybe because I cannot see a benefit in rebuild the same code as before.

It's just like a car, you can paint wings on it, but it won't fly either.

~Florian

[Former Member]

no it doesn't. I do it step by step. I'm pretty sure the big problems are generating the interface. You know, most of the inserted code somewhere between form-routines is using global parameters and there are the problems.
Don't shoot me, but I really do not see your problem here.

My way is every single line of code I have to touch during the year is transformed to OO, no matter if static or instance.
At that moment I have to touch the code I build an class and put the "old" form-coding into the class and build an interface. 

And I demand tooling support for this tedious task, that's it.

I do NOT want to *automatically* refactor all form routines into methods 1:1,

I just want the ADT feature of "extract into method" to work on form-routine-code too to help me refactor the routines step by step!

Of course an ADT-feature like "extract into Interface" would be very welcome too....

[larshp]

Hi,

Good idea and nice discussion.

I've put some work into a prototype that will take all FORMs and add it as static methods in a global class, it works outside of Eclipse. Its still in its early stages so expect some issues, source code is available at

larshp/FORMfactor · GitHub

Comments/ideas/issues/pull requests welcome

[ThFiedler]

Very nice.

Any plans to integrate this with the Eclipse editor as Quick Assist?

Regards,

Thomas.

[Former Member]

Thank you very much for your effort, Lars!

Now, ADT-guys, you should be able to provide that as a quick-assist as well, don't you?

[larshp]

Could be fun, I've added it as an issue in the tracker Eclipse quick assist? · Issue #3 · larshp/FORMfactor · GitHub

Though it might be some more work to factor it per FORM, and I'm not sure if that would be the typical use case. Rewriting a complete program at a time might be more typical, hmm

[larshp]

Hi,

Bit more progress today, new project created:

larshp/FORMfactor-Eclipse · GitHub

The quick assist now shows up in Eclipse for FORM and PERFORMs, though no logic has been implemented yet,

[vonglan]

Hi,

we are just switching to ADT, and I found this discussion because I ran into the same question.

In my first example, I already started doing the conversion from FORM to local class method manually (which was quick), but then I encountered the Problem that Header tables cannot be used any more in OO.

So, in Addition to the "FORM to local method" refactoring, it would be great to have an "Header table to table+structure" refactoring.

I also think this (FORM refactoring) is a huge (valuable) use case, because most (maybe all) SAP customer have massive amounts of Z-Coding in FORMs. So it would be worth a lot to get some tool-help for migrating the FORMs to local methods, and replacements of the most common obsolete Syntax (where it is not too difficult to implement) like table headers.

(Maybe also a market for companies like SmartShift that offer "code Transformation Services".)

Best regards,

Edo

[joachimrees1]

This all was a good read and it made me search for (and find!) a similar question I've had even longer ago:

https://answers.sap.com/questions/7842885/automatic-generation-of-abap-classes-from-function.html

🙂