Modularisierung wie handhaben?
Hallo,
ich versuche beim Entwickeln, so viel wie möglich zu modularisieren.
Entweder anhand von Performs, Fubas, Methoden etc.
Aber was mache ich, wenn ich nur ein paar Zeilen habe, die ich z.b. in mehrere Performs einfügen muss?
Aktueller Fall:
Diese Abfrage habe ich jetzt in zwei Unterroutinen eingebaut. Wenn später einmal was hinzukommen sollte, muss ich oder ein anderer sich Gedanken machen, wo es noch geändert werden sollte. Edit: Aufwendig. Da je nach Szenario entweder die eine oder die andere Unterroutine aufgerufen wird.
Da wo gv_nast gefüllt wird, habe ich schon in ein Perform gepackt, weil es schon einige Zeilen Code sind.
Wenn ich die obige Abfrage auch in ein Perform reinpacke, dann habe ich ja nur noch Performs, was für die Übersichtlichkeit ja auch nicht gerade gut ist oder?
Wie löst ihr solche Fälle?
Viele Grüße
coco
ich versuche beim Entwickeln, so viel wie möglich zu modularisieren.
Entweder anhand von Performs, Fubas, Methoden etc.
Aber was mache ich, wenn ich nur ein paar Zeilen habe, die ich z.b. in mehrere Performs einfügen muss?
Aktueller Fall:
Code: Alles auswählen.
IF gv_ebeln IS NOT INITIAL.
SHIFT gv_ebeln BY 1 PLACES LEFT.
MESSAGE i017(06) WITH text-006 gv_ebeln.
ENDIF.
IF gv_nast IS NOT INITIAL.
SHIFT gv_nast BY 1 PLACES LEFT.
MESSAGE i900(06) WITH gv_nast.
ENDIF.Da wo gv_nast gefüllt wird, habe ich schon in ein Perform gepackt, weil es schon einige Zeilen Code sind.
Code: Alles auswählen.
PERFORM prozess_message USING lf_rc
ls_eq45_po
lf_ebeln
CHANGING <fs_cush>.Wie löst ihr solche Fälle?
Viele Grüße
coco
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Nach bissle Rumkucken habe ich Makros entdeckt.
Eigentlich könnte ich ja die paar Zeilen in ein Macro packen.
Aber ich hab auch von den Nachteilen über Macros gelesen, nämlich dass sie im Debugger nicht durchlaufen werden.
Jetzt ist die Frage: soll ich oder soll ich nicht...
Gruß
coco
Eigentlich könnte ich ja die paar Zeilen in ein Macro packen.
Aber ich hab auch von den Nachteilen über Macros gelesen, nämlich dass sie im Debugger nicht durchlaufen werden.
Jetzt ist die Frage: soll ich oder soll ich nicht...
Gruß
coco
Hallo Ingo,
danke für deine Antwort.
Ja genau das schreckt mich eben auch ab. Ich hab in alten Reports gesehen, dass da Makros eingesetzt werden, aber auch nur, weil ich im editor gesucht habe und nicht im debugger.
Benutzt du auch den Perform, wenn da nur 2 Zeilen Code ist?
Viele Grüße
coco
danke für deine Antwort.
Ja genau das schreckt mich eben auch ab. Ich hab in alten Reports gesehen, dass da Makros eingesetzt werden, aber auch nur, weil ich im editor gesucht habe und nicht im debugger.
Benutzt du auch den Perform, wenn da nur 2 Zeilen Code ist?
Viele Grüße
coco
Beitrag
von a-dead-trousers (Top Expert / 4483 / 231 /
1205
)
»
hi!
Ich persönlich verwend die Makros sehr gerne, aber nur wenn ich z.B. Feldsymbol verwende, die man leider nicht an Methoden weiterreichen kann bzw. nur für sich wiederholenden Code.
Eine weitere Möglichkeit, wäre bei den Forms eine "generische" Schnittstelle zu verwenden und anhand des Typs des Übergabeparameters unterschiedliche Verarbeitungen aufzurufen.
Dazu kann man entweder DESCRIBE verwenden oder wenns detailierter sein muss, ginge auch RTTI (CL_ABAP_TYPEDESCR).
Beispiel:
lg ADT
Ich persönlich verwend die Makros sehr gerne, aber nur wenn ich z.B. Feldsymbol verwende, die man leider nicht an Methoden weiterreichen kann bzw. nur für sich wiederholenden Code.
Eine weitere Möglichkeit, wäre bei den Forms eine "generische" Schnittstelle zu verwenden und anhand des Typs des Übergabeparameters unterschiedliche Verarbeitungen aufzurufen.
Dazu kann man entweder DESCRIBE verwenden oder wenns detailierter sein muss, ginge auch RTTI (CL_ABAP_TYPEDESCR).
Beispiel:
Code: Alles auswählen.
FORM show_message USING ud_data.
DATA:
lr_type TYPE REF TO cl_abap_typedescr.
lr_type = cl_abap_typedescr=>describe_by_data( ud_data ).
CASE lr_type->type_kind.
WHEN cl_abap_typedescr=>typekind_string.
MESSAGE ud_data TYPE 'S'.
WHEN cl_abap_typedescr=>typekind_int.
MESSAGE NUMBER ud_data TYPE 'S'.
...
ENDCASE.
ENDFORM.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hallo Coco,c oco hat geschrieben:Hallo Ingo,
danke für deine Antwort.
Ja genau das schreckt mich eben auch ab. Ich hab in alten Reports gesehen, dass da Makros eingesetzt werden, aber auch nur, weil ich im editor gesucht habe und nicht im debugger.
Benutzt du auch den Perform, wenn da nur 2 Zeilen Code ist?
Viele Grüße
coco
oft ja, da sich aufgrund von immer wieder neuen Anforderungen sehr oft die entsprechende Notwendigkeit ergibt.
Aber ich denke das musst Du individuell entscheiden.
Bei zwei Aufrufen denke ch brauchst Du das nicht unbedingt, danach wird es dann schon wegen der Pflege einfacher...
Viele Grüße
Ingo
Beitrag
von ralf.wenzel (Top Expert / 4009 / 208 /
282
)
»
Gerade darum muss sich jeder von mir ne Zigarre abholen, in dessen Code ich Makros finde.inab hat geschrieben:Makros sind schön, aber gemein ....
Schon beim lesen eines 'fremden' codes muss man drauf kommen, das dort ein Makro aufgerufen wird.
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
So hat jeder seine Vorlieben und ich würde die Zigarre von Dir ignorieren - oder sie genüsslich rauchenGerade darum muss sich jeder von mir ne Zigarre abholen, in dessen Code ich Makros finde.
.Denn Makros kann man wie viele Elemente einer Progammiersprache mehr oder weniger sinnvoll verwenden, z.B:,
- Für gleichartige sich wiederholende Selection-Screen Anweisungen oder Datendeklarationen (Debugging nicht erforderlich),
- oder Coding-Strecken, die z.B. einen Exit oder Return oder Check zum Verlassen einer Routine beinhalten.
- oder Berechtigungsprüfungen, bei denen man verhindern möchte, daß per Debug/Replace Werte geändert werden können (erhöhte Sicherheit)
Möchte hier keinen Glaubenskrieg ausfechten - wollte einfach nur meinen Senf dazu geben.
Gruß dele
Makros sind von SAP als obsolet gekennzeichnet. Von daher sollte man es vermeiden, sie bei neuen Entwicklungen einzusetzen. Bei vielen Kunden ist es laut Programmierrichtlinie eh verboten, obsolete Statements zu verwenden.
Beitrag
von black_adept (Top Expert / 4158 / 136 /
959
)
»
Ich hoffe du hast einen guten Draht zu einem größeren Zigarrenimporteur, falls SAP mal dein Posting hier lesen sollte.ralf.wenzel hat geschrieben:Gerade darum muss sich jeder von mir ne Zigarre abholen, in dessen Code ich Makros finde.inab hat geschrieben:Makros sind schön, aber gemein ....
Schon beim lesen eines 'fremden' codes muss man drauf kommen, das dort ein Makro aufgerufen wird.
Beitrag
von black_adept (Top Expert / 4158 / 136 /
959
)
»
Ab welchem Release sollen denn Makros obsolet sein? Wäre doch traurig auf das schöne "break <meinusername>" verzichten zu müssen.dnuc hat geschrieben:Makros sind von SAP als obsolet gekennzeichnet. Von daher sollte man es vermeiden, sie bei neuen Entwicklungen einzusetzen. Bei vielen Kunden ist es laut Programmierrichtlinie eh verboten, obsolete Statements zu verwenden.
Beitrag
von ralf.wenzel (Top Expert / 4009 / 208 /
282
)
»
Erstens hat die SAP schon so einiges von mir gelesen, was ihr nicht behagte und zweitens rät selbst die SAP von sowas ab.
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von Alexander D. (Expert / 682 / 30 /
84
)
»
die Aussage war für mich auch neu. Habe ein wenig Google bemüht und bislang folgendes gefunden:black_adept hat geschrieben: Ab welchem Release sollen denn Makros obsolet sein?
bei SAPHelp für NW70 ist von "obsolete" nicht viel zu sehen:
http://help.sap.com/saphelp_nw70/helpda ... ontent.htm
und bei NW70 EHP2 bzw. EHP3 steht tatsächlich, dass die Makros veraltet sind:
http://help.sap.com/saphelp_nw70ehp2/he ... ontent.htm
schöne Grüße
Alexander
ECC 6.0 EHP 7
Alexander
ECC 6.0 EHP 7
wovon SAP abrät, ist vollkommen irrelevant. Warum:
- sie nutzen die "obsoleten" Sprachelemente selbst massiv und denken offensichtlich nicht daran das zu ändern. (Im Workflow werden Makros extrem genutzt)
---> dies gilt insbesondere für Performance
- nutzt nicht jeder Entwickler und Berater auch (und wahrscheinlich in der Mehrzahl) Funktionsbausteine, die von SAP nicht freigegeben sind ?
- wieviele Ankündigungen von SAP haben sich im Sand verlaufen oder wurden zurückgenommen (contexte, Type-pools, smart-forms, BSP, .....) ?
Ich will damit nicht sagen, dass alle Empfehlungen von SAP unsinnig sind. Aber ein gesunder und pragmatischer Menschenverstand ist wichtiger.
Und zum eigentlichen Thema:
Modulaisierung ist sehr zu empfehlen (In vielen SAP-Programmen wäre das sehr zu wünschen).
Aber eine pauschale Empfehlung, wo und wann bzw. ab wann, macht keinen Sinn. Das hängt zu sehr vom Kontext ab. Entscheidungskriterien könnten sein:
- Wiederverwendbarkeit (dann eher Methode oder Funktionsbaustein)
- Wahrscheinlichkeit der mehrfachen Nutzung
- Lesbarkeit eines Programmes
- und nicht zuletzt auch: einfacheres Testen (Debuggen)
gruß dele
- sie nutzen die "obsoleten" Sprachelemente selbst massiv und denken offensichtlich nicht daran das zu ändern. (Im Workflow werden Makros extrem genutzt)
---> dies gilt insbesondere für Performance
- nutzt nicht jeder Entwickler und Berater auch (und wahrscheinlich in der Mehrzahl) Funktionsbausteine, die von SAP nicht freigegeben sind ?
- wieviele Ankündigungen von SAP haben sich im Sand verlaufen oder wurden zurückgenommen (contexte, Type-pools, smart-forms, BSP, .....) ?
Ich will damit nicht sagen, dass alle Empfehlungen von SAP unsinnig sind. Aber ein gesunder und pragmatischer Menschenverstand ist wichtiger.
Und zum eigentlichen Thema:
Modulaisierung ist sehr zu empfehlen (In vielen SAP-Programmen wäre das sehr zu wünschen).
Aber eine pauschale Empfehlung, wo und wann bzw. ab wann, macht keinen Sinn. Das hängt zu sehr vom Kontext ab. Entscheidungskriterien könnten sein:
- Wiederverwendbarkeit (dann eher Methode oder Funktionsbaustein)
- Wahrscheinlichkeit der mehrfachen Nutzung
- Lesbarkeit eines Programmes
- und nicht zuletzt auch: einfacheres Testen (Debuggen)
gruß dele
Vergleichbare Themen
1
Antw.
Antw.
907
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.