Deklarationen: Tabellarisch oder nicht?

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
69 Beiträge • Vorherige Seite 3 von 5 (current) Nächste
69 Beiträge Vorherige Seite 3 von 5 (current) Nächste

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
ralf.wenzel hat geschrieben:Das ist ja nicht alles. Ich zum Beispiel rücke NIE innerhalb einer Anweisung ein...
Moin Ralf,

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 ). 
anstatt

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 ) ).
ein - bzw. rückst du das tatsächlich nicht ein wenn es nicht auf eine Zeile passt?
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
black_adept hat geschrieben: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 ). 
anstatt

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 ). 
?
Nein, ich mag keine langen Zeilen, weil der Debugger die nicht komplett anzeigt (rechts habe ich meine Werkzeuge), weshalb ich sie vermeide:

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 ). 
Hinweis: Ich trenne zwei Anweisungen IMMER durch eine Leerzeile von den benachbarten ab (wenige begründete Ausnahmen), darum brauche ich keine Einrückung innerhalb einer Anweisung um sie von anderen Anweisungen abzugrenzen.
black_adept hat geschrieben:Oder wie rückst du

Code: Alles auswählen.

wert = my_class=>my_method( value #( field1 = wert1
                                     field2 = wert2
                                     .....
                                     fieldn = wertn ) ).
ein - bzw. rückst du das tatsächlich nicht ein wenn es nicht auf eine Zeile passt?
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:

Code: Alles auswählen.

class->method(
  bla
  blub
).
Bei Verkettungen rückt die Schnittstelle natürlich mit nach rechts, so dass ich optisch sehen kann, welcher Parameter zu welcher Methode gehört.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von Daniel (Specialist / 314 / 68 / 44 ) »
black_adept hat geschrieben: so lange ich ihn vernünftig lesen kann.
Das ist leider manchmal nicht der Fall.
black_adept hat geschrieben:
... der gute Herr Wirth scheint prägend gewesen zu sein
Den sollten mache mal lesen

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Daniel hat geschrieben:
black_adept hat geschrieben: so lange ich ihn vernünftig lesen kann.
Das ist leider manchmal nicht der Fall.
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:
black_adept hat geschrieben:
... der gute Herr Wirth scheint prägend gewesen zu sein
Den sollten mache mal lesen
Man sollte so einiges mal lesen.....


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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.
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.

/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.

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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.
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.

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
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von Daniel (Specialist / 314 / 68 / 44 ) »
ralf.wenzel hat geschrieben: Man sollte so einiges mal lesen.....
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.
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.

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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.
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.
Ich weise immer gerne wieder auf Nicolas Bourbaki hin, in dessen Lehrbüchern diese Vorgehensweise schon vor 80 Jahren angewandt wurde.

@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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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.
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.
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.

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
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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.
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".


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von Daniel (Specialist / 314 / 68 / 44 ) »
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".
Ich gehöre zu diesen Leuten.
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.

Re: Deklarationen: Tabellarisch oder nicht?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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.
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.

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
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Vergleichbare Themen

4
Antw.
2311
Views
Textsymbole in Deklarationen
von SteJu » 02.06.2008 09:02 • Verfasst in ABAP® für Anfänger
17
Antw.
4776
Views
Grundsatzfrage: Deklarationen
von ralf.wenzel » 12.12.2013 21:51 • Verfasst in ABAP® Core
33
Antw.
2962
Views
Alle Deklarationen in FORM Routinen ermitteln
von Tron » 01.10.2019 11:26 • Verfasst in ABAP® Core

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140