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.
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 )
)
).
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!
)
)
).
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!
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.
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!
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.
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.
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".
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?
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.
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", ...).
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?
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
tar
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.
Nein. Ja. Ich öffne den Editor nichtmal mehr.