Umherspringende Methoden im quelltextbasierten Class Builder
Das Grundproblem ist doch, dass man das beliebig weiter verschachteln kann. Wie weit rechts willst du denn da landen? Noch ein paar plastischere Beispiele, um dir zu zeigen, warum nach rechts zu erweitern die Lesbarkeit erschwert:DeathAndPain hat geschrieben: ↑21.10.2024 18:04Und da behaupte ich, dass das nicht nur kürzer (weniger Zeilen) ist, sondern sich zugleich auch besser liest. Und wenn das so ist, dann werde ich es nicht anders machen, um irgendwelche Formalien zu genügen, die mutmaßlich von Konstrukten wie Schleifen oder IF-Blöcken stammen. Dass man zwischen LOOP und ENDLOOP oder IF und ENDIF einrückt, da bin ich voll dafür. Das liest sich wunderbar. Aber das ist doch kein Grund, dieses Prinzip zwanghaft auch auf Situationen anzuwenden, bei denen es die Lesbarkeit tatsächlich sogar verschlechtert.
Tabellen-Inline-Deklaration und verschachtelte Methoden:
Code: Alles auswählen.
data(lt_anlagen) = value lr_anlagen(
( sign = |I| option = |EQ| low = ro_result->ms_log-anlage_einspeisung )
( sign = |I| option = |EQ| low = ro_result->ms_log-anlage_messlokation )
( sign = |I| option = |EQ| low = ro_result->ms_log-anlage_netznutzung_bezug )
( sign = |I| option = |EQ| low = ro_result->ms_log-anlage_netznutzung_einspeiser )
).
ro_result->set_log_error(
lo_zaehler_ausbau->add_measurement(
iv_ableseart = |01| " Ablesung durch EVU - SAP
iv_ablesedatum = lv_stichtag
iv_ablesegrund = |22| " Ablesung bei abrechnungstechn. Ausbau
iv_ablesehinweis = |10| " Zählerausbau
iv_zaehlwerk = <zaehlwerk>-nr
iv_zaehlerstand = conv #( ro_result->ms_einspeiser-zaehler_ausbau_stand_182 )
)
).Schön zu sehen, sind hier übrigens auch die noch lesbaren Kurzkommentare. Die richte ich, insofern möglich, auf Spalte 70 aus, weil soweit "rechts drüben" im Regelfall kein Code steht und es somit ins Äuglein sticht, ohne den Codefluss zu stören. Bräuchte ich jetzt neben iv_zaehlerstand noch einen Kommentar, könnte ich problemlos den Klammerinhalt nach conv # umbrechen. Wenn auch das nicht mehr geht, wandert der Kommentar halt 5-10 Zeichen weiter nach rechts, aber eben keine 3 Seiten 😄
Bei dir wäre das alles schon schwieriger und man müsste im Zweifel regelmäßig immer weiter nach rechts schauen, wenn nicht gar ständig nach rechts scrollen. Um dem zu entgehen, müsstest du auf Side-Comments verzichten oder Unterstrukturen als separate Hilfsvariablen deklarieren, was ebenfalls schlechter Stil ist. Zudem stehen bei dir jegliche Parameter aufeinanderfolgender Methoden, Deklarationen, usw. usf. völlig anders ausgerichtet da - eben je nachdem, wie lang der jeweilige Methodenname ist. Das ist nicht nur nicht schön, sondern auch nicht lesbarer.
Anderes Beispiel. Inline-Deklaration mit verschachtelten Switches:
Code: Alles auswählen.
data(lv_tariftyp) = switch ty_history-tariftyp(
io_wob->mv_messart
when io_wob->c_messart-rlm then |T1| " hello monsieur
when io_wob->c_messart-slp then switch #(
ms_properties-art
when 'G102' then switch #(
io_wob->ms_allgemein-ms_hinweis
when 'ALLGEMEINANLAGE'
or 'HAUSHALT'
or 'NIEDRIGENERGIEHAUS' then |T2| " hier wird was gesetzt
when 'GEWERBE'
or 'INDUSTRIE'
or 'LANDWIRTSCHAFT' then |T3| " ei-der-daus!
)
else switch #(
io_wob->ms_allgemein-ms_hinweis
when 'ALLGEMEINANLAGE'
or 'HAUSHALT'
or 'NIEDRIGENERGIEHAUS' then |T4| " hier auch
when 'GEWERBE'
or 'INDUSTRIE'
or 'LANDWIRTSCHAFT' then |T5| " und hier erst - potzBLITZ!
)
)
).Deine Variante sähe hingegen wie folgt aus:
Code: Alles auswählen.
data(lv_tariftyp) = switch ty_history-tariftyp( io_wob->mv_messart when io_wob->c_messart-rlm then |T1|
when io_wob->c_messart-slp then switch #( ms_properties-art when 'G102' then switch #( io_wob->ms_allgemein-ms_hinweis when 'ALLGEMEINANLAGE'
or 'HAUSHALT'
or 'NIEDRIGENERGIEHAUS' then |T2|
when 'GEWERBE'
or 'INDUSTRIE'
or 'LANDWIRTSCHAFT' then |T3| )
else switch #( io_wob->ms_allgemein-ms_hinweis when 'ALLGEMEINANLAGE'
or 'HAUSHALT'
or 'NIEDRIGENERGIEHAUS' then |T4|
when 'GEWERBE'
or 'INDUSTRIE'
or 'LANDWIRTSCHAFT' then |T5| ) ) ).Findest du, Dumps zu erzwingen statt Exceptions zu werfen oder noch besser: den Fehler direkt zu behandeln (und wenn es ein Message Type E ist), nicht irgendwie seltsam?DeathAndPain hat geschrieben: ↑21.10.2024 18:04Zugleich sorge ich damit aber auch dafür, dass mein Programm spektakulär auf die Nase fällt, wenn ich einen Denkfehler gemacht habe und es die Zeile doch mal nicht gibt. Dann ist ein Dump genau richtig, denn wenn das Programm sich in einer Weise verhält, bei der ich als Programmierer überzeugt bin, dass das gar nicht passieren kann, dann habe ich einen Denkfehler gemacht und sein Verhalten ist undefiniert.
Nein, auch wenn ich insb. deren 1. Zeichen (L..., I..., R... usw.) geradewegs nicht als überflüssig, sondern als sehr nützlich erachte. Ferner würde mich interessieren, wie man ohne dem 2. Zeichen bspw. auf Anhieb erkennt, dass es sich um eine Tabelle mit mehreren Status handelt.DeathAndPain hat geschrieben: ↑21.10.2024 18:04Was Du da machen willst, ist eine Erweiterung der eh schon überflüssigen ungarischen Notation.
Hä? Ich meinte "klare Entitäten" mit nur 1 Schlüssel, den man der Einfachheit halber auch direkt "ID" nennen sollte. Gibt es mehrere Schlüssel, dann heißen die hier nicht "ID_irgendwas", sondern geradewegs inhaltlich, was sie bedeuten ("Auftragsnr", "Positionsnr", ...).DeathAndPain hat geschrieben: ↑21.10.2024 18:04...weil Du ja - aus meiner Sicht komplett unmotiviert - alphabetisch sortieren möchtest. Also müsstest Du sie ID1..., ID2... usw. nennen. Sorry, aber was für ein Krampf!
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von ralf.wenzel (Top Expert / 3879 / 198 /
277
)
»
Nein, auch wenn ich insb. deren 1. Zeichen (L..., I..., R... usw.) geradewegs nicht als überflüssig, sondern als sehr nützlich erachte. Ferner würde mich interessieren, wie man ohne dem 2. Zeichen bspw. auf Anhieb erkennt, dass es sich um eine Tabelle mit mehreren Status handelt.[/quote]DeathAndPain hat geschrieben: ↑21.10.2024 18:04Was Du da machen willst, ist eine Erweiterung der eh schon überflüssigen ungarischen Notation.
Ich sage nix dazu. Bei Ungarischer Notation flippe ich sonst immer aus. Aber ich werde altersmilde 😉
Ein Feld, das ID heißt, kann alles sein. Feldnamen sollten sprechend sein.Hä? Ich meinte "klare Entitäten" mit nur 1 Schlüssel, den man der Einfachheit halber auch direkt "ID" nennen sollte. Gibt es mehrere Schlüssel, dann heißen die hier nicht "ID_irgendwas", sondern geradewegs inhaltlich, was sie bedeuten ("Auftragsnr", "Positionsnr", ...).DeathAndPain hat geschrieben: ↑21.10.2024 18:04...weil Du ja - aus meiner Sicht komplett unmotiviert - alphabetisch sortieren möchtest. Also müsstest Du sie ID1..., ID2... usw. nennen. Sorry, aber was für ein Krampf!
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Bei Entitäten ist das aber eine unnütze Zusatzinfo, die du ja gerade auch bei der ungarischen Notation ankreidest: Auftrag-ID statt Auftrag-Auftragsnr sieht nicht nur eleganter aus, sondern liest und schreibt sich auch schöner.ralf.wenzel hat geschrieben: ↑22.10.2024 10:02Ein Feld, das ID heißt, kann alles sein. Feldnamen sollten sprechend sein.
Bei Objekten mit mehreren oder unklaren Schlüsseln bin ich jedoch ganz bei dir.
Zuletzt geändert von tar am 22.10.2024 19:38, insgesamt 1-mal geändert.
Beitrag
von ralf.wenzel (Top Expert / 3879 / 198 /
277
)
»
Das heißt ja, dass das Auftragsnummernfeld in der Kopftabelle einen anderen Namen hat als in der Positionstabelle. Finde ich schwierig.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3879 / 198 /
277
)
»
Weil ein gleiches Feld den gleichen Namen haben sollte. Schon für move-corresponding und Co. Wenn ein Feldname davon abhängig ist in welcher Tabelle es steht und nicht davon, welchen semantischen Inhalt es hat, finde ich das schwierig.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3879 / 198 /
277
)
»
Also, ein Kunde ist etwas anderes als ein Partner. Bei PARNR und PARTNER geb ich dir recht, das ist nicht nachzuvollziehen. Ich ärgere mich oft darüber, dass semantisch gleiche Felder bei der SAP unterschiedliche Namen haben.
KNUMV und KNUMH beruhen auf verschiedenen Datenelementen und Domänen, darum gehe ich davon aus, dass das semantisch nicht dasselbe ist.
Ralf
KNUMV und KNUMH beruhen auf verschiedenen Datenelementen und Domänen, darum gehe ich davon aus, dass das semantisch nicht dasselbe ist.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Wer legt das denn fest? Bspw. sind im IS-U Geschäftspartner (BUT000 etc.) - du ahnst es vielleicht: Kunden. Je nach Kontext sind es Debitoren oder Kreditoren, oft sogar beides (bspw. als Stromkunde mit Einspeisung). Und nun?
Da gibt es zig Felder, die auf dieselbe Domäne verweisen und dennoch eine unterschiedliche Bedeutung haben und umgekehrt. Man schaue sich da bloß nicht die VBFA und die darin enthaltenen VBELV und VBELN an, die beide über dieselbe Domäne auf die VBUK referenzieren, obwohl in der VBFA auch Bestellungen (Hallo EBELN!) referenziert werden, die sich nicht in der VBUK befinden.ralf.wenzel hat geschrieben: ↑22.10.2024 19:50KNUMV und KNUMH beruhen auf verschiedenen Datenelementen und Domänen, darum gehe ich davon aus, dass das semantisch nicht dasselbe ist.
Die Semantik ist eben von vornherein nicht auf den Tabellennamen der Schlüsseltabelle festgemeiselt, sondern ergibt sich in deren Verwendung, d.h. durch den Kontext des Fremdschlüssels und was er in der jeweiligen Tabelle repräsentiert. Daher sind bspw. EKKO-KUNNR und VBAK-KUNNR semantisch verschieden, auch wenn sie gleich heißen. Ein MOVE-CORRESPONDING kann hier ggf. verheerende Folgen haben.
Aber du zieltest ja auf die Primärtabelle ab - dass man hier flink aus der KNA1 selektieren und "correspond moven" kann, was ich jedoch für kein Argument halte. Nicht nur, weil CORRESPONDING ein Mapping ermöglicht, sondern vor allem, weil du obendrein auf den herzuleitenden Kontext verzichtest, den du sprechender und damit verständlicher in deiner Zielstruktur festlegen könntest, womit wir wieder beim SAP-Blödsinn wären, wo die KUNNR einmal der Besteller und ein andermal der Auftraggeber ist. Wieso SAP das nicht mittlerweile einfach Besteller und Auftraggeber nennt, ist klar: Rückwärtskompatibilität samt Begrenzung der Feldnamenlänge (wrsl. wg. der grundsätzlichen Architektur).
Aber was macht man in der Regel, wenn man eine Struktur aufbaut, die mehrfach denselben Fremdschlüssel referenziert: man benennt sie entsprechend - und so wird aus KUNNR eben einmal Auftraggeber und Warenempfänger usw. Wie auch immer man das dann konkret nennt: die Gleichnamigkeit ist dahin.
Beitrag
von ralf.wenzel (Top Expert / 3879 / 198 /
277
)
»
Du widersprichst mir und gibst mir dann recht. Ein Geschäftspartner ist etwas anderes als ein Kunde, weil ein Kunde immer ein Kunde ist, ein Geschäftspartner aber nicht. Er kann ein Kunde sein, muss aber nicht.
Das macht die Felder semantisch verschiedene. Und ein Auftraggeber ist ebenso ein Kunde wie ein Besteller. Oder bin ich kein Amazon-Kunde, weil ich dort bestelle?
Ralf
Das macht die Felder semantisch verschiedene. Und ein Auftraggeber ist ebenso ein Kunde wie ein Besteller. Oder bin ich kein Amazon-Kunde, weil ich dort bestelle?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Es ist ein semantischer Unterschied, ob du Besteller oder Auftraggeber bist.
1. Wieso nennt SAP beides KUNNR?
2. Wieso willst du diesen Blödsinn in eigenen Strukturen beibehalten?
3. Was machst du, wenn du beide - Besteller und Auftraggeber - in 1 Struktur abbilden möchtest?
1. Wieso nennt SAP beides KUNNR?
2. Wieso willst du diesen Blödsinn in eigenen Strukturen beibehalten?
3. Was machst du, wenn du beide - Besteller und Auftraggeber - in 1 Struktur abbilden möchtest?
Beitrag
von DeathAndPain (Top Expert / 1876 / 240 /
406
)
»
Horizontal scrollen musst Du allenfalls im Debugger, weil der noch mit Bildformaten aus dem letzten Jahrtausend arbeitet (und das ist noch nicht mal eine Übertreibung). In Eclipse werden mir die Zeilen durch meine genannten Formatierungsstrategien niemals so breit, dass nicht alles auf den Bildschirm passen würde. Selbst die SE38 zeigt mittlerweile auch genug auf dem Schirm, so dass das da auch nicht passiert.ralf.wenzel hat geschrieben: ↑21.10.2024 21:06Also, ich finde es furchtbar, horizontal scrollen zu müssen, darum sind mir "mehr, kurze" Zeilen lieber als "weniger, breite".
Dabei muss ich einräumen, dass ich mit einem vernünftigen Monitor arbeite. Ich weiß nicht, wie es wäre, wenn man mit einem Mininotebook mit dem heutzutage leider sehr verbreiteten Displayformat von erbärmlichen 14 oder 15" arbeitet. Auf sowas kann man in meinen Augen ebenso wenig sinnvoll entwickeln, wie man auf den dazugehörigen Quetschtastaturen tippen kann. (Bildschirm und Tastatur hängen zusammen, weil sich bei Notebooks aus der Bildschirmbreite auch die zur Verfügung stehende Breite für die Tastatur ergibt - schließlich baut niemand ein Notebook breiter als sein Display.) Nichts gegen Notebooks, aber man daran auch einen ordentlichen Bildschirm anschließen (und eine ordentliche Tastatur). Auch wenn die Dockingstationen von heute nicht mehr das sind, was sie mal waren (mit nur einem USB-Kabel mit wackligem Stecker, durch das alles fließen muss und das sich häufig als Flaschenhals entpuppt). Davon abgesehen gibt es auch Notebooks mit 17". Damit arbeitet es sich auch ohne externe Hardware schon bedeutend angenehmer, und die Tastaturlayouts sind auch bedeutend natürlicher. Das Transportproblem finde ich bedeutend weniger dramatisch, als es gemeinhin angenommen wird. Jedenfalls für männliche Zeitgenossen.
Völlig unabhängig von der optischen Codeaufbereitung führt zu tiefe Verschachtelung zu immer schlechter verständlichem Code. Das sieht man an dem von Dir aufgeführten Negativbeispiel: da sind meine und Deine Variante beide richtig mies verständlich, und man muss erst mal in Ruhe gucken und nachdenken, was da passiert. Ich bin mitnichten ein Fan davon, für jeden kleinen Zwischenschritt eine eigene Workarea-Variable zu definieren, aber wenn die Komplexität zu groß wird, dann ergibt das durchaus Sinn. Dann machst Du erst mal einen oder zwei Switches in ein inline-definiertes Zwischenfeld, das einen sprechenden Namen trägt (dem man ansieht, wofür es steht) und verwendest dieses Zwischenfeld dann in Deinem Hauptausdruck. Dann ist das gut lesbar und verständlich (wobei der Name des Zwischenfeldes wie ein zusätzlicher Kommentar wirkt, der dem Leser veranschaulicht, aus was für Elementen Du Deinen Hauptausdruck zusammenbaust). Zugleich senkst Du auch drastisch die Gefahr von Bugs, denn diese ist bei sehr komplexen Ausdrücken, die nur noch schwer zu überblicken sind, immer deutlich erhöht.tar hat geschrieben:Das Grundproblem ist doch, dass man das beliebig weiter verschachteln kann. Wie weit rechts willst du denn da landen?
Die Kehrseite ist, dass der Kommentar dadurch so weit vom Quellcode entfernt steht, dass man nicht mehr gut sieht, zu welcher Zeile er eigentlich gehört.tar hat geschrieben:Schön zu sehen, sind hier übrigens auch die noch lesbaren Kurzkommentare. Die richte ich, insofern möglich, auf Spalte 70 aus, weil soweit "rechts drüben" im Regelfall kein Code steht und es somit ins Äuglein sticht, ohne den Codefluss zu stören.
Nicht, wenn ich als Programmierer fest davon ausgehe, dass der Fehler gar nicht passieren kann. Messages sind gut für Fehler, die sich aus den Daten oder aus den Benutzereingaben ergeben. Was für eine Message Type E willst Du dem Anwender in diesem Fall geben? "Es ist ein Fehler aufgetreten, der nicht hätte passieren dürfen. Das Programm funktioniert also nicht ordentlich. Ich mache weiter, aber gehen Sie davon aus, dass die Ausgaben nichts taugen und falsche Daten in die Datenbank geschrieben werden." Ist es das, was Du dem Anwender anzeigen willst?tar hat geschrieben:Findest du, Dumps zu erzwingen statt Exceptions zu werfen oder noch besser: den Fehler direkt zu behandeln (und wenn es ein Message Type E ist), nicht irgendwie seltsam?
Ok, das war sarkastisch, man würde den Programmablauf dann wohl eher beenden, als undefiniert fortzufahren. Aber dennoch: mit einer Nachricht, dass das Programm nicht ordentlich funktioniert und daher abgebrochen werden muss, ist keinem Anwender gedient. Da finde ich einen Dump sogar nützlicher: der sagt nämlich dasselbe aus, aber da kann ich nachher in der ST22 eine Menge Informationen finden, die oft schon reichen, die Ursache zu ergründen. Allein schon die Information, dass es ein ASSERT war und welcher, reicht doch schon fast aus, die Ursache zu ergründen. Bei Deiner Herangehensweise würde Dir der Anwender nur mit einem Screenshot sagen, dass er eine Fehlermeldung bekommen hat, und dann kannst Du auf die Suche gehen, wo diese Fehlermeldung geworfen wird und hast immer noch nicht die Daten, die der Situation zugrunde gelegen haben.
ASSERT benutze ich nur, wenn ich als Entwickler überzeugt davon bin, dass es nie anders sein kann. Ist es doch anders, dann liegt ein grundsätzlicher Programmierfehler vor, der behoben werden muss.
Zum einen aus dem sprechend gewählten Namen. Wenn das Feld PERSONALNUMMERN heißt, dann ist offensichtlich, dass mehr als eine drin sein wird, was ein erdrückender Hinweis auf eine interne Tabelle ist.tar hat geschrieben:Ferner würde mich interessieren, wie man ohne dem 2. Zeichen bspw. auf Anhieb erkennt, dass es sich um eine Tabelle mit mehreren Status handelt.
Zum anderen aus der Verwendung. Bei den meisten Befehlen ist direkt aus dem Befehl offensichtlich, dass es eine interne Tabelle sein muss, z.B. bei LOOP AT xyz oder ASSIGN xyz[ abc = def ] TO <hahaha>. In den Fällen, in denen es nicht offensichtlich ist, pflege ich die alte []-Syntax zu verwenden: CLEAR xyz[]. (Wobei ich in diesem Fall gar nicht CLEAR schreiben würde, sondern noch sprechender den alten REFRESH-Befehl verwende. Ich weiß, dass der deprecated ist, aber er ist super sprechend und eindeutig, genau wie die gleichfalls als "veraltet" eingestuften Befehle ADD, SUBTRACT etc., bei denen sich die erdrückende Mehrheit im Forum hier einig ist, dass sie nach wie vor nützlich sind.) An allen Stellen, bei denen es nicht offensichtlich ist, dass es sich um eine interne Tabelle handelt, kannst Du das [] hinter den Namen stellen. Du wirst allerdings feststellen, dass das nur recht seltene Fälle sind. Fast immer ergibt sich aus dem Befehl bzw. Konstrukt zwingend, dass es sich um eine interne Tabelle handelt. Bei Methodenaufrufen kann man so aber sehr schön signalisieren, dass es sich um einen Tabellenparameter handelt.
So sehe ich das auch. Aber dann darfst Du die Spalten nicht alphabetisch sortieren, weil sich sonst eben Deine Schlüsselspalten wild über die Tabelle verteilen. Sowas gehört in der Schlüsselreihenfolge an den Anfang der Tabellenstruktur.tar hat geschrieben:Hä? Ich meinte "klare Entitäten" mit nur 1 Schlüssel, den man der Einfachheit halber auch direkt "ID" nennen sollte. Gibt es mehrere Schlüssel, dann heißen die hier nicht "ID_irgendwas", sondern geradewegs inhaltlich, was sie bedeuten ("Auftragsnr", "Positionsnr", ...).
Davon abgesehen scheinst Du mir andeuten zu wollen, dass bei der erdrückenden Mehrheit der internen Tabellen der Schlüssel nur eine Spalte lang sei. Das halte ich für ein Gerücht und ein Indiz für einen schlecht gewählten Schlüssel. Und auch wenn der korrekte Schlüssel tatsächlich nur eine Spalte umfasst, hat diese immer noch eine Bedeutung und sollte deren Namen tragen (also z.B. LAGERORT heißen und nicht ID, wo sich der Leser dann erst mal fragt, was für eine ID das denn sein soll).
Ich bin Deiner Meinung, aber nicht speziell aus diesem Grund, denn MOVE-CORRESPONDING kannst Du immer durch ein CORRESPONDING# ()-Konstrukt ersetzen und hast dann die Möglichkeit, den MAPPING-Operator zu nutzen.Ralf hat geschrieben:Weil ein gleiches Feld den gleichen Namen haben sollte. Schon für move-corresponding und Co.
Nach derlei Logik darfst Du nicht fragen. In den SAP HCM-Tabellen (z.B. PA0001) heißt der Personalbereich immer WERKS, obwohl dieses Kürzel bereits im MM existiert und dort eine ganz andere Bedeutung hat. Das zugehörige Datenelement heißt dementsprechend PERSA, und in der Schlüsseltabelle T500P der Personalbereiche heißt auch das Feld PERSA. Es gibt keinen nachvollziehbaren Grund, weshalb die SAP für den Personalbereich nicht überall PERSA verwendet, sondern dasselbe Feld in vielen Tabellen WERKS nennt. Und dennoch haben sie es so gemacht.tar hat geschrieben:1. Wieso nennt SAP beides KUNNR?
Je nach Anwendungsfall könntest Du Unterstrukturen für die bestellerbezogenen Felder und die auftraggeberbezogenen Felder definieren und diese mit INCLUDE TYPE unter Nutzung des Zusatzes RENAMING WITH SUFFIX einbinden und den Namen damit eindeutig machen. Das CORRESPONDING würde man dann wie zuvor erwähnt als Operator mit dem MAPPING-Zusatz ausformulieren. Oder man nutzt beim INCLUDE TYPE auch den AS NAME-Zusatz und kann dann darüber die Teilfelder ansprechen.tar hat geschrieben:3. Was machst du, wenn du beide - Besteller und Auftraggeber - in 1 Struktur abbilden möchtest?
Ich gebe Dir allerdings recht, dass das je nach Anwendungsfall mit Kanonen auf Spatzen geschossen sein kann.
Beitrag
von black_adept (Top Expert / 4042 / 117 /
925
)
»
@tar und D&P: Warum einigt ihr euch nicht einfach darauf, dass ihr halt unterschiedliche Auffassungen habt, was die Ästhetik der Codeformatierung angeht.
Und wenn ich mir die Diskussion gerade anschaue bzgl. wie tief man einrücken sollte: Ja, D&P hat so eine Idee wie man etwas machen sollte, aber wenn man im Einzelfall dann feststellt, dass die Grundidee hier einfach schlecht aussieht macht man es halt anders. Und ich schätze, dass auch tar niemanden vierteilen wird, wenn er an der einen oder anderen Stelle leicht anders formatiert als die Vorgabe, wenn es dadurch besser lesbar wird.
Wenn ich mir z.B. ein Programm von ewx anschaue, denke ich mir immer "so würde ich das nicht machen". Aber ich weiß halt, dass Enno sich Gedanken gemacht hat und dass er seine Gründe hat, warum er schreibt wie er schreibt. Er und ich haben halt andere Prioriäten, aber ich denke, dass die meisten Entwickler sich sowohl in seinen als auch in meinem Code gut zurechtfinden werden.
Vielleicht noch ein Hinweis zum irgendwo angesprochenen Pretty Printer: SAP schraubt hier andauernd dran rum, gerade was Einrückungen angeht. @D&P: Ich glaube mich zu erinnern, dass wenn man in sehr neuen Releases z.B. nach Exporting direkt in die gleiche Zeile den ersten Parameter schreibt bzw. den Zeilenumbruch manuell entsorgt, der PP den Rest nach dem gleichen Schema angleicht.
Und wenn ich mir die Diskussion gerade anschaue bzgl. wie tief man einrücken sollte: Ja, D&P hat so eine Idee wie man etwas machen sollte, aber wenn man im Einzelfall dann feststellt, dass die Grundidee hier einfach schlecht aussieht macht man es halt anders. Und ich schätze, dass auch tar niemanden vierteilen wird, wenn er an der einen oder anderen Stelle leicht anders formatiert als die Vorgabe, wenn es dadurch besser lesbar wird.
Wenn ich mir z.B. ein Programm von ewx anschaue, denke ich mir immer "so würde ich das nicht machen". Aber ich weiß halt, dass Enno sich Gedanken gemacht hat und dass er seine Gründe hat, warum er schreibt wie er schreibt. Er und ich haben halt andere Prioriäten, aber ich denke, dass die meisten Entwickler sich sowohl in seinen als auch in meinem Code gut zurechtfinden werden.
Vielleicht noch ein Hinweis zum irgendwo angesprochenen Pretty Printer: SAP schraubt hier andauernd dran rum, gerade was Einrückungen angeht. @D&P: Ich glaube mich zu erinnern, dass wenn man in sehr neuen Releases z.B. nach Exporting direkt in die gleiche Zeile den ersten Parameter schreibt bzw. den Zeilenumbruch manuell entsorgt, der PP den Rest nach dem gleichen Schema angleicht.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
tar
Lagerort.Id - ja, was wird mit "Id" hier wohl gemeint sein? Genau: ein Fahrrad! 🤭
Interessiert dich überhaupt, ob dein Code im ABAP-Editor noch irgendwie verständlich aussieht oder ist Eclipse dein einziger Maßstab?
Was ist eigentlich mit jenen, die deinen Code in 5 Jahren warten müssen? Die werden sich ganz besonders freuen, wenn sie erstmal herumscannen dürfen, was denn die notationsfreien Variablen genau für einen Typ (Werte, Strukturen, Tabellen oder Referenzen) haben, ob sie nur interne Hilfskonstrukte sind oder Eingabeparameter oder Rückgaben sind. Alles sehr durchdacht. Weiter so! Im gleichen Zug schimpfst du aber auf Klasseninstanzen und dass es schwierig ist, da durchzublicken 🤪
Wie kann man bzgl. interner Tabellen nur weiter mit [], Clear und Refresh hantieren!? Das sind indirekte Hinweise auf die etwaige Nutzung von Kopfzeilen 🤢
Sorry... ist doch alles nicht zum aushalten, was für Verrenkungen du hier anführst.
Nicht, wenn man übliche Formatierungskonventionen einhält. Falls das SWITCH zu unverständlich ist, könnte man auch COND verwenden - das würde in deiner Schreibart aber alles nur noch weiter nach rechts rücken. Klar, dass du da nach im Grunde überflüssigen Hilfskonstruktionen suchst.Völlig unabhängig von der optischen Codeaufbereitung führt zu tiefe Verschachtelung zu immer schlechter verständlichem Code.
Interessiert dich überhaupt, ob dein Code im ABAP-Editor noch irgendwie verständlich aussieht oder ist Eclipse dein einziger Maßstab?
Was ist eigentlich mit jenen, die deinen Code in 5 Jahren warten müssen? Die werden sich ganz besonders freuen, wenn sie erstmal herumscannen dürfen, was denn die notationsfreien Variablen genau für einen Typ (Werte, Strukturen, Tabellen oder Referenzen) haben, ob sie nur interne Hilfskonstrukte sind oder Eingabeparameter oder Rückgaben sind. Alles sehr durchdacht. Weiter so! Im gleichen Zug schimpfst du aber auf Klasseninstanzen und dass es schwierig ist, da durchzublicken 🤪
Wie kann man bzgl. interner Tabellen nur weiter mit [], Clear und Refresh hantieren!? Das sind indirekte Hinweise auf die etwaige Nutzung von Kopfzeilen 🤢
Sorry... ist doch alles nicht zum aushalten, was für Verrenkungen du hier anführst.
Beitrag
von ralf.wenzel (Top Expert / 3879 / 198 /
277
)
»
Nein. Ja. Ich öffne den Editor nichtmal mehr.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Vergleichbare Themen
10
Antw.
Antw.
2298
Views
Views
3
Antw.
Antw.
4882
Views
Views
Interne Tabelle in Class Builder definieren
von mamaierhofer » 20.03.2007 16:14 • Verfasst in ABAP Objects®
von mamaierhofer » 20.03.2007 16:14 • Verfasst in ABAP Objects®
5
Antw.
Antw.
6445
Views
Views
Abstrakte Methode im Class Builder anlegen
von jay-tee » 18.12.2006 14:22 • Verfasst in ABAP Objects®
von jay-tee » 18.12.2006 14:22 • Verfasst in ABAP Objects®
5
Antw.
Antw.
2900
Views
Views
Class Builder: Default für Meth.param. gepackt mit Dezimalen
von Gast » 06.02.2006 13:57 • Verfasst in ABAP Objects®
von Gast » 06.02.2006 13:57 • Verfasst in ABAP Objects®
0
Antw.
Antw.
2318
Views
Views
Solution Builder (Build Block Builder)
von SAP_ENTWICKLER » 19.12.2018 09:59 • Verfasst in Sonstige Module
von SAP_ENTWICKLER » 19.12.2018 09:59 • Verfasst in Sonstige Module
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 17 Stunden von ralf.wenzel 47 / 4793
vor 17 Stunden von ralf.wenzel 47 / 4793
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 17 Stunden von ralf.wenzel 47 / 4793
vor 17 Stunden von ralf.wenzel 47 / 4793