Deklarationen: Tabellarisch oder nicht?
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Ich bin kein Freund von Ausnahmen. Wiedererkannte Muster erleichtern das Lesen von Coding. Und spätestens beim Join muss das FROM in eine eigene Zeile.
Übrigens kam ich drauf, dass das Tabellarische in anderen Sprachen unüblich ist, weil die nicht mit Proportionalschriften arbeiten. So ein bisschen nach Keilschrift sieht das ja schon aus im SAP-Editor
Ralf
Übrigens kam ich drauf, dass das Tabellarische in anderen Sprachen unüblich ist, weil die nicht mit Proportionalschriften arbeiten. So ein bisschen nach Keilschrift sieht das ja schon aus im SAP-Editor
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Moin Ralf,ralf.wenzel hat geschrieben:Das ist ja nicht alles. Ich zum Beispiel rücke NIE innerhalb einer Anweisung ein...
schreibst du tatsächlich
Code: Alles auswählen.
LOOP AT itab ASSIGNING FIELD-SYMBOL(<wa>) WHERE ( Bedingung_1 ) AND ( Bedingung_2 ) ... AND ( Bedingung_m )
AND ( Bedingung_m+1 ) ..... AND ( Bedingung_n ). Code: Alles auswählen.
LOOP AT itab ASSIGNING FIELD-SYMBOL(<wa>) WHERE ( Bedingung_1 )
AND ( Bedingung_2 )
.....
AND ( Bedingung_m )
AND ( Bedingung_m+1 )
.....
AND ( Bedingung_n ). Oder wie rückst du
Code: Alles auswählen.
wert = my_class=>my_method( value #( field1 = wert1
field2 = wert2
.....
fieldn = wertn ) ).
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Nein, ich mag keine langen Zeilen, weil der Debugger die nicht komplett anzeigt (rechts habe ich meine Werkzeuge), weshalb ich sie vermeide:black_adept hat geschrieben:schreibst du tatsächlichanstattCode: Alles auswählen.
LOOP AT itab ASSIGNING FIELD-SYMBOL(<wa>) WHERE ( Bedingung_1 ) AND ( Bedingung_2 ) ... AND ( Bedingung_m ) AND ( Bedingung_m+1 ) ..... AND ( Bedingung_n ).?Code: Alles auswählen.
LOOP AT itab ASSIGNING FIELD-SYMBOL(<wa>) WHERE ( Bedingung_1 ) AND ( Bedingung_2 ) ..... AND ( Bedingung_m ) AND ( Bedingung_m+1 ) ..... AND ( Bedingung_n ).
Code: Alles auswählen.
LOOP AT itab
ASSIGNING FIELD-SYMBOL(<wa>)
WHERE ( Bedingung_1 )
AND ( Bedingung_2 )
AND ( Bedingung_m )
AND ( Bedingung_m+1 )
AND ( Bedingung_n ). Ich breche nach der Klammer, die die Schnittstelle einläutet, um und rücke diese so ein, dass sie um zwei Stellen zum Klassen-/Objektnamen eingerückt ist, die schließende Klammer fängt in der Spalte an, in der der Ausdruck aufhört:black_adept hat geschrieben:Oder wie rückst duein - bzw. rückst du das tatsächlich nicht ein wenn es nicht auf eine Zeile passt?Code: Alles auswählen.
wert = my_class=>my_method( value #( field1 = wert1 field2 = wert2 ..... fieldn = wertn ) ).
Code: Alles auswählen.
class->method(
bla
blub
).Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Ok - Jeder macht es wohl so wie er es für sinnvoll hält. Und mir ist es auch meistens egal wie andere ihren Code formatieren - so lange ich ihn vernünftig lesen kann.
Ich habe meine Präferenzen und sehe natürlich gerne wenn jemand anders analog zu meiner Philosophie formatiert wie z.B. Thomas R mit seinen Einrückungen bei komplexen logischen Ausdrücken ( @Thomas R. Ich habe auch mit Pascal angefangen - der gute Herr Wirth scheint prägend gewesen zu sein ).
Aber wenn ich mir fremde Programme anschaue scheinen die meisten einen brauchbaren Stil gefunden zu haben. Abgesehen von der mysteriösen 3-Spaltenformatierung sind doch alle bisher beschriebenen Vorgehensweisen nicht so verschieden, auch wenn leicht differierende Philosphien dahinter stecken.
Ich habe meine Präferenzen und sehe natürlich gerne wenn jemand anders analog zu meiner Philosophie formatiert wie z.B. Thomas R mit seinen Einrückungen bei komplexen logischen Ausdrücken ( @Thomas R. Ich habe auch mit Pascal angefangen - der gute Herr Wirth scheint prägend gewesen zu sein ).
Aber wenn ich mir fremde Programme anschaue scheinen die meisten einen brauchbaren Stil gefunden zu haben. Abgesehen von der mysteriösen 3-Spaltenformatierung sind doch alle bisher beschriebenen Vorgehensweisen nicht so verschieden, auch wenn leicht differierende Philosphien dahinter stecken.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Alles richtig, aber wenn in einem Team ein Produkt entwickelt wird, sollte es aussehen wie aus einer Hand. Dann möchte ich an den Formatierungen nicht sehen, wer das Coding geschrieben hat.
Denn für den Kunden, der das Produkt lizensiert hat, sollte es möglichst einheitlich sein.
Ralf
Denn für den Kunden, der das Produkt lizensiert hat, sollte es möglichst einheitlich sein.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Das ist leider manchmal nicht der Fall.black_adept hat geschrieben: so lange ich ihn vernünftig lesen kann.
Den sollten mache mal lesenblack_adept hat geschrieben:
... der gute Herr Wirth scheint prägend gewesen zu sein
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Die Frage ist: Was kann man vernünftig lesen? Es gibt Leute, die sagen "was mit PP formatiert ist, kann ich nicht gescheit lesen". Führt dann u. U. dazu, dass er sagt "wehe, du machst PP in meinen Programmen, dann kann ich ja mein Coding nicht mehr lesen und muss alles von Hand neu formatieren"....Daniel hat geschrieben:Das ist leider manchmal nicht der Fall.black_adept hat geschrieben: so lange ich ihn vernünftig lesen kann.
Man sollte so einiges mal lesen.....Daniel hat geschrieben:Den sollten mache mal lesenblack_adept hat geschrieben:
... der gute Herr Wirth scheint prägend gewesen zu sein
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Also, wir haben ja zu fünft ein Buch geschrieben.ralf.wenzel hat geschrieben:Alles richtig, aber wenn in einem Team ein Produkt entwickelt wird, sollte es aussehen wie aus einer Hand. Dann möchte ich an den Formatierungen nicht sehen, wer das Coding geschrieben hat.
Einzig der Lektorin ist es zu verdanken, dass man nicht (kaum) mehr erkennen kann, wer welches Kapitel geschrieben hat.
/edit
Der Verlag hat einen Autorenleitfaden in dem genau drin steht, wie bestimmte Dinge zu schreiben sind.
zum Beispiel muss alles aktivistisch geschrieben und in der Reihenfolge beschrieben werden, in der Dinge gemacht werden müssen.
Aus
"Sie sehen das Ergebnis, nachdem Sie den Sichern-Button betätigt haben"
wird dann:
"Betätigen Sie den Sichern-Button. Sie sehen dann das Ergebnis.".
Das wird knallhart vom Lektor durchgezogen. Egal, ob jemanden der Stil nicht gefällt.
Der Witz bleibt so übrigens weitestgehend auf der Strecke. Was wahrscheinlich auch beabsichtigt ist.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Genau solche Regeln braucht man für Coding auch, sonst heißt ein Objekt für einen Vertriebsauftrag mal "sd_bel" und mal "v_bel" und mal "auftrag". Und bei den Klassen hat man dann cl_auftrag_.... und mal cl_vbel_...., obwohl in beiden Fällen das gleiche gemeint ist, nämlich ein Unterobjekt zum Vertriebsauftrag.ewx hat geschrieben:Also, wir haben ja zu fünft ein Buch geschrieben.
Einzig der Lektorin ist es zu verdanken, dass man nicht (kaum) mehr erkennen kann, wer welches Kapitel geschrieben hat.
Feste Begriffe aus dem Projekt (in meinem gerade z. B. "Untersuchungsauftrag") müssen einheitlich definiert sein, damit nicht der eine "uauftrag", der nächste "untersuchungsauftrag" und der dritte noch was anderes schreibt (natürlich die jeweiligen englischen Begriffe, deutsche sollte man unterlassen).
Wie ich immer sage: Wiedererkennung rulez!
Der Lektor in einem Projekt ist der Entwicklungskoordinator, der sollte auf solche Dinge achten.
Die halten sich aber lieber damit auf, drei Tage einen SCI zu konfigurieren, der meckert, weil man nicht "lt_..." schreibt oder weil eine Methode zu kurz (!) ist oder weil man die 30% Comment Ratio unterschreitet (obwohl man eine Doku in SAPscript geschrieben hat, die am Entwicklungsobjekt hängt). Das sind wohl die drei dämlichsten Prüfungen, die mir je begegnet sind. Weil dann nämlich jede SET/GET-Methode angemeckert wird mit der Begründung "eine Zeile kann man doch direkt reinschreiben" - was zeigt, dass der Koordinator nicht verstanden hat, was ein privates Attribut ist und warum man das schützt. OO sechs, Setzen!
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Der Traum das alles wiederverwendbar wird wenn man nurralf.wenzel hat geschrieben: Man sollte so einiges mal lesen.....
bestimmte Regeln/Techniken verwendet wird seit 40 Jahren
immer wieder hervorgeholt. Nur funktioniert hat es noch nie.
Wirklich wiederverwendbares Coding entsteht wenn ich das
von Anfang an will und die Disziplin habe das durchzuhalten.
Mit welcher Technik das realisiert wird ist belanglos.
Dafür ist viel wichtiger das Programme gut lesbar sind. Nicht
umsonst ist ABAP im Ursprung eine Spache die man fast so
gut wie Prosa lesen kann. Die Väter des ABAP waren alle
gestandene Assembler-Programmierer und wussten genau was
Sie taten. Diese Überzeugug habe ich von heutigen Entwicklern
nicht. Da ist zu viel Ideologie im Spiel.
Programme im SAP-Umfeld werden oft 15 oder 20 Jahre lang
genutzt. In dieser Zeit werden mehrere Programmierer daran
arbeiten. Wenn jeder sich mit viel Aufwand einarbeiten muss
kann man das Programm besser entsorgen und neu schreiben.
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
ralf.wenzel hat geschrieben:Alles richtig, aber wenn in einem Team ein Produkt entwickelt wird, sollte es aussehen wie aus einer Hand. Dann möchte ich an den Formatierungen nicht sehen, wer das Coding geschrieben hat.
Ich weise immer gerne wieder auf Nicolas Bourbaki hin, in dessen Lehrbüchern diese Vorgehensweise schon vor 80 Jahren angewandt wurde.ewx hat geschrieben:Also, wir haben ja zu fünft ein Buch geschrieben.
Einzig der Lektorin ist es zu verdanken, dass man nicht (kaum) mehr erkennen kann, wer welches Kapitel geschrieben hat.
@Ralf: Grundsätzlich stimme ich dir - ausnahmsweise - mal zu. Aber die Bemerkung gilt immer nur für einen Zeitpunkt - wenn sich im Laufe der Zeit die Richtlinien ändern, z.B. weil der Richtlinienbeauftragte etwas hinzugelernt hat stellt sich dann die Frage: Was ist besser? "Alles aus einem Guss" oder "Ab jetzt mit besserer Formatierung", da der theoretisch korrekte Ansatz "Alles aus einem Guss mit besserer Formatierung" wohl selten genehmigt wird.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Daniel hat geschrieben: Der Traum das alles wiederverwendbar wird wenn man nur
bestimmte Regeln/Techniken verwendet wird seit 40 Jahren
immer wieder hervorgeholt. Nur funktioniert hat es noch nie.
Wirklich wiederverwendbares Coding entsteht wenn ich das
von Anfang an will und die Disziplin habe das durchzuhalten.
Mit welcher Technik das realisiert wird ist belanglos.
Die Zeit, in der ABAP entstanden ist, war die Zeit, in der die Programme deutlich übersichtlicher waren als das heute der Fall ist. Gerade beim Kunden entstehen heute sehr komplexe Anwendungen. Und auch wenn jetzt andere nicht mitreden können: Eine ZCEIN wäre in endlosen IF/ELSEIF-Unterscheidungen geendet, die einem jedesmal das Coding zerschneidet. Durch den OO-Ansatz hatte ich verschiedene Variationen von Aufträgen, die alle aus derselben Oberklasse erben.Daniel hat geschrieben:Das ist nicht ganz richtig - weil es nicht nur um Wiederverwendbarkeit geht im Sinne von "das habe ich schonmal programmiert", OO geht viel weiter in der Abstraktion.
Daniel hat geschrieben:Dafür ist viel wichtiger das Programme gut lesbar sind. Nicht
umsonst ist ABAP im Ursprung eine Spache die man fast so
gut wie Prosa lesen kann. Die Väter des ABAP waren alle
gestandene Assembler-Programmierer und wussten genau was
Sie taten. Diese Überzeugug habe ich von heutigen Entwicklern
nicht. Da ist zu viel Ideologie im Spiel.
Programme im SAP-Umfeld werden oft 15 oder 20 Jahre lang
genutzt. In dieser Zeit werden mehrere Programmierer daran
arbeiten. Wenn jeder sich mit viel Aufwand einarbeiten muss
kann man das Programm besser entsorgen und neu schreiben.
Gerade der Einarbeitung wegen ist OO ganz gut - weil man eben die Daten mit der Logik zusammenhalten kann (das nennt sich dann Objekt). Ich muss also gar nicht wissen, wie ein Fertigungsauftrag angelegt wird, wenn das in dem Objekt gekapselt ist, das auch die Daten dazu enthält. So erhalte ich in sich geschlossene, funktionierende Einheiten, die miteinander kommunizieren.
OO wird oft auf Vererbung und Wiederverwendung reduziert, das ist aber nur ein ganz kleiner Teil des OO-Ansatzes. Wir entwickeln hier gerade ein sehr komplexes Modul, das ohne OO praktisch kaum wartbar wäre, weil das Modul in seiner Gesamtheit mit all seinen Wechselwirkungen keiner mehr in Gänze versteht (so wie auch eine Person nicht alle Prozesse des Unternehmens erklären kann). Und dann sind so in sich geschlossene Module eben praktisch, weil die deutlich übersichtlicher sind.
Und man spart sich eine Menge Coding, weil man deutlich abstrakter arbeiten kann (z. B. mit Schnittstellen) - diesem Abstraktionsgrad muss man dann natürlich folgen (das ist das Problem bei den meisten SAP-Anwendungen, weil die Doku fehlt). Aber man muss eben nicht das ganze Unternehmen verstehen, denn die Abstraktionstechniken sind ja überall dieselben.
Du weißt das aus den fast sechs Jahren, die wir zusammengearbeitet haben: Es hat eine ganze, Weile gedauert, bis ich OO was abgewinnen konnte - inzwischen entwickele ich nur noch auf besonderen Wunsch prozedural, weil es eine ganze Menge Dinge gibt, die prozedural einfach nicht oder nur nahezu unlesbar gehen. Mich graust es, wenn ich einen 3.000-Zeiler durchdebuggen muss um ihn zu verstehen, statt in Modulen zu denken.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Innerhalb eines Projektes sollte alles aus einem Guss sein. Ennos Verlag ändert auch nicht die Regeln und sagt "OK, ab Seite 100 machen wir das jetzt anders".black_adept hat geschrieben:@Ralf: Grundsätzlich stimme ich dir - ausnahmsweise - mal zu. Aber die Bemerkung gilt immer nur für einen Zeitpunkt - wenn sich im Laufe der Zeit die Richtlinien ändern, z.B. weil der Richtlinienbeauftragte etwas hinzugelernt hat stellt sich dann die Frage: Was ist besser? "Alles aus einem Guss" oder "Ab jetzt mit besserer Formatierung", da der theoretisch korrekte Ansatz "Alles aus einem Guss mit besserer Formatierung" wohl selten genehmigt wird.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Ich gehöre zu diesen Leuten.ralf.wenzel hat geschrieben: Die Frage ist: Was kann man vernünftig lesen? Es gibt Leute, die sagen "was mit PP formatiert ist, kann ich nicht gescheit lesen".
Der PP wurde gebaut als eine Zeile noch max. 72 Stellen
haben durfte. Trotzdem muss jedes mögliche Coding in
eine solche Zeile passen. Es ich daher ein sehr schlechter
Kompromiss. Ich habe den PP mittlerweile modifiziert so
daß meine Programme nicht mehr bearbeitet werden.
Ich Verwende große Sorgfalt auf eine strukturierte und gut
lesbare Formatierung. Das lasse ich mir von einem schlechten
PP nicht zerstören.
Es gab zwar schon immer Menschen die davon irritiert waren,
aber noch niemand hat jemals behauptet das wäre schlecht
lesbar oder unübersichtlich. Und darauf kommt es an.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Das ist nicht der Punkt, aber du hast mich mal fast aus dem Fenster geworfen, nur weil ich an deinem Programm was gemacht habe und natürlich (statt das alles händisch zu machen) den PP verwendet habe. Denn damit war ja "deine" Formatierung kaputt.Daniel hat geschrieben:Es gab zwar schon immer Menschen die davon irritiert waren,
aber noch niemand hat jemals behauptet das wäre schlecht
lesbar oder unübersichtlich. Und darauf kommt es an.
Schön, dass du das inzwischen anders gelöst hast, denn ich hab schon mit Leuten telefoniert, die völlig am Boden zerstört waren, weil du sie aus dem gleichen Grund zur Sau gemacht hast. Nicht jeder kann soviel ab wie ich
DAS mit dem Fenster war ein Problem, nicht die Lesbarbarkeit. Ich kann nämlich nicht fliegen.
Ralf *eine Methode, die mehr als eine Seite lang ist, ist potentiell zu komplex
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Vergleichbare Themen
4
Antw.
Antw.
2582
Views
Views
17
Antw.
Antw.
5090
Views
Views
33
Antw.
Antw.
3908
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.