Ich nutze zwar kein Eclipse, aber das sieht sehr gut aus - bis auf eine Sache, die ich auch hier immer mal wieder sehe und nicht nachvollziehen kann:rob_abc hat geschrieben: ↑18.10.2024 21:42Ich habe inzwischen aufgegeben und nutze ABAP Cleaner: https://github.com/SAP/abap-cleaner
Code: Alles auswählen.
... value #( line_id = sy-tabix
typerino = <component>-type
element_length = <component>-length
display_name = <component>-name
is_something = abap_true ) ...
Code: Alles auswählen.
... value #(
display_name = <component>-name
element_length = <component>-length
is_something = abap_true
line_id = sy-tabix
typerino = <component>-type
) ...
Code: Alles auswählen.
SELECT mbew~*,
mara~mtart,
mara~meins,
t001~waers
FROM mbew
INNER JOIN
mara ON mara~matnr = mbew~matnr
INNER JOIN
t001k ON t001k~bwkey = mbew~bwkey
INNER JOIN
t001 ON t001~bukrs = t001k~bukrs
WHERE mbew~bwkey = @g_select_options-werks
AND mbew~lbkum > 0
INTO CORRESPONDING FIELDS OF TABLE @l_db_mbew.
Code: Alles auswählen.
SELECT mbew~*,
mara~mtart,
mara~meins,
t001~waers
FROM mbew
INNER JOIN mara ON mara~matnr = mbew~matnr
INNER JOIN t001k ON t001k~bwkey = mbew~bwkey
INNER JOIN t001 ON t001~bukrs = t001k~bukrs
WHERE mbew~bwkey = @g_select_options-werks
AND mbew~lbkum > 0
INTO CORRESPONDING FIELDS OF TABLE @l_db_mbew.
Code: Alles auswählen.
select wmeng as auftragsmenge,
vbeln as auftragsnr,
bmeng as bestaetigte_menge,
edatu as datum,
etenr as nr,
posnr as positionsnr,
ettyp as typ
into corresponding fields of table @mt_einteilungen
from vbep for all entries in @it_eintraege
where vbeln = @it_eintraege-auftragsnr
and posnr = @it_eintraege-positionsnr
and ( wmeng > 0
or bmeng > 0 ).
select distinct vbak~auart as auftragsart,
vbap~kwmeng as auftragsmenge,
vbak~vbeln as auftragsnr,
vbap~matnr as materialnr,
vbap~posnr as positionsnr,
vbap~pstyv as positionstyp
into table @data(lt_auftragspositionen)
from vbak
inner join vbuk on vbuk~vbeln = vbak~vbeln
and vbuk~gbstk <> @lcl_top=>c_vollstaendig " gesamtbearbeitungsstatus
inner join vbap on vbap~vbeln = vbak~vbeln
and vbap~abgru = @space
where vbak~vkorg in @pt_verkaufsorganisationen
and vbap~werks in @pt_werke.
INTO CORRESPONDING beeinträchtigt die Performance negativ bei:
Da bin ich ganz deutlich anderer Meinung. Das VALUE alleine in eine Zeile zu schreiben und dann in der nächsten Zeile weiterzumachen, ist der gleiche Mist, den der Pretty Printer z.B. mit Funktionsbausteinen macht (wo dann die Schlüsselwörter EXPORTING etc. alleine in einer Zeile stehen). Das wirkt unmotiviert und zieht den Code in die Länge (es passt weniger ins Fenster) und zugleich wird es schlechter lesbar. Ich finde die erste Version in Deinem Beispiel erheblich besser lesbar, pflichte in diesem Fall also Clean ABAP voll bei.tar hat geschrieben: ↑19.10.2024 01:48Ich nutze zwar kein Eclipse, aber das sieht sehr gut aus - bis auf eine Sache, die ich auch hier immer mal wieder sehe und nicht nachvollziehen kann:
Stattdessen ist diese Einrückung sauberer und die alphabetische Sortierung lesbarer:Code: Alles auswählen.
... value #( line_id = sy-tabix typerino = <component>-type element_length = <component>-length display_name = <component>-name is_something = abap_true ) ...
Code: Alles auswählen.
... value #( element_length = <component>-length display_name = <component>-name is_something = abap_true line_id = sy-tabix typerino = <component>-type ) ...
Dem stimme ich zu, da INNER JOINs letztlich alle gleichrangig sind, so dass die weiteren Einrückungen eine Hierarchie suggerieren, die es überhaupt nicht gibt.Rob_abc hat geschrieben:Ich habe sie einfach untereinander geschrieben. Verstehe nicht, was das weitere Einrücken bringen soll.
Beim SELECT-Befehl gibt es in meinen Augen viele gut lesbare Herangehensweisen, die ich alle für legitim halte. Da ist es nur wichtig, dass sich der Autor überhaupt um eine erkennbare Formatierung bemüht hat. Was mir bei Deiner Version auffällt, ist etwas, was ich auch mache, aber sonst niemals bei irgend jemandem sehe und daher als gutes Indiz nutzen kann, auf einen Blick zu erkennen, welcher Code von mir ist und welcher nicht: INTO vor FROM. Nach meinem Dafürhalten war das einst bei SQL sogar so vorgeschrieben, jedenfalls bei Informix 4GL war diese Reihenfolge Pflicht. In ABAP schreibt aber sonst jeder zuerst FROM und danach erst INTO. ABAP akzeptiert beides.tar hat geschrieben:SELECTS gestalte ich grundsätzlich so:
Tatsächlich halte ich nicht viel von gepufferten Datenbanktabellen. Bei einzelnen Zugriffen ist die Performance egal, und wenn ich oft auf die Tabelle zugreifen muss, dann puffere ich mir die relevanten Spalten in eine interne Tabelle (je nach Situation SORTED oder HASHED) mit passendem Schlüssel. Darauf zuzugreifen ist nochmal viel performanter als jeder Zugriff auf gepuffterte Datenbanktabellen (und als Bonbon kann ich den Suchschlüssel genau so definieren, wie ich ihn für mein Programm optimalerweise brauche).tar hat geschrieben:INTO CORRESPONDING beeinträchtigt die Performance negativ bei:
- gepufferten Tabellen (hier sollte man einfach SELECT * nutzen)
Am besten beides und dann nicht INTO CORRESPONDING FIELDS OF TABLE, sondern einfach INTO TABLE. Das ist performanter. Macht heute freilich nicht mehr nennenswert was aus, aber in Zeiten früherer Releases (und der damit einhergehenden alten Hardware) hat das einen richtig wahrnehmbaren Unterschied gemacht.tar hat geschrieben:- vielen Selektionsfeldern bei nicht-gepufferten Tabellen, die es auch in der Zielstruktur gibt (hier sollte man die konkreten Felder angeben, entweder im SELECT oder in der Typisierung der Zielstruktur oder beides)
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
ralf.wenzel
Wenn ich etwas von A nach B lege, dann sage ich im normalen Sprachgebrauch IMMER erst, von wo und dann nach wo ich es lege. Sieht man ja schon am Anfang des Satzes.DeathAndPain hat geschrieben: ↑20.10.2024 18:02INTO vor FROM. Nach meinem Dafürhalten war das einst bei SQL sogar so vorgeschrieben, jedenfalls bei Informix 4GL war diese Reihenfolge Pflicht. In ABAP schreibt aber sonst jeder zuerst FROM und danach erst INTO. ABAP akzeptiert beides.
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
Xilukarim
Das hat mit einer konsistenten Formatierungsausrichtung zu tun, die in vielen gängigen Programmiersprachen so festgelegt ist, dass Unterbestandteile grundsätzlich einen Tabstopp eingerückt werden und vor allem, dass deren Abschluss wieder am Zeilenbeginn der übergeordneten Struktur endet. Beispiel:DeathAndPain hat geschrieben: ↑20.10.2024 18:02Das VALUE alleine in eine Zeile zu schreiben und dann in der nächsten Zeile weiterzumachen, ist der gleiche Mist, den der Pretty Printer z.B. mit Funktionsbausteinen macht (wo dann die Schlüsselwörter EXPORTING etc. alleine in einer Zeile stehen). Das wirkt unmotiviert und zieht den Code in die Länge (es passt weniger ins Fenster) und zugleich wird es schlechter lesbar. Ich finde die erste Version in Deinem Beispiel erheblich besser lesbar, pflichte in diesem Fall also Clean ABAP voll bei.
Code: Alles auswählen.
data(lo_person) = new lcl_person(
age = 43
gender = c_male
name = value #(
first = |Archibald|
last = |Tuttle|
)
).
Du kannst das doch halten, wie du magst. Du siehst aber generell nicht per se, welche Felder Teil des Primärschlüssels sind - immer erst nach dem Absprung in die DB-Tabelle und da finde ich die meist nicht sprechenden Spaltennamen fürchterlich und möchte nicht ständig hin- und herspringen müssen, um zu wissen, was sie bedeuten, sondern orientiere mich an der verständlicheren Benamung der Zielstruktur, die ich selbst vornehmen kann, danach sortiere und dadurch sofort sehe, welche inhaltlichen Informationen genutzt werden. Die Behandlung der Primärschlüssel findet sich indes im WHERE und ON, wobei ich das so wie du mache, obwohl die dortige Sortierung der DB selbst eigentlich egal ist.DeathAndPain hat geschrieben: ↑20.10.2024 18:02Über alphabetische Reihenfolge kann man streiten. Mir gefällt es besser, mich an die Reihenfolge aus der Strukturdefinition zu halten, allein schon deshalb, weil man dann bei solch VALUE besser erkennen kann, welche Spalten ggf. weggelassen worden sind. Außerdem ist es guter Stil, Primärschlüsselspalten an den Anfang der Struktur zu setzen (bei Datenbanktabellen und den daraus gebildeten Strukturen sind sie ja immer dort). Wenn man das alphabetisch umsortiert, dann sind die Primärschlüsselspalten wild über die Struktur verteilt. Halte ich für fürchterlich.
Ein weiterer Grund ist die optische Aufbereitung:DeathAndPain hat geschrieben: ↑20.10.2024 18:02INTO vor FROM. Nach meinem Dafürhalten war das einst bei SQL sogar so vorgeschrieben, jedenfalls bei Informix 4GL war diese Reihenfolge Pflicht. In ABAP schreibt aber sonst jeder zuerst FROM und danach erst INTO. ABAP akzeptiert beides.
Code: Alles auswählen.
select erdat as erstellungsdatum,
vbeln as id
from vbak
where vkorg = '4711'
and kunnr = '0815'
into table @lt_auftraege.
Die neue Ultima Ratio von SAP ist das INTO ans Ende der Anweisung ( also hinter WHERE und ORDER ) zu stellen.DeathAndPain hat geschrieben: ↑20.10.2024 18:02Beim SELECT-Befehl gibt es in meinen Augen viele gut lesbare Herangehensweisen, die ich alle für legitim halte. Da ist es nur wichtig, dass sich der Autor überhaupt um eine erkennbare Formatierung bemüht hat. Was mir bei Deiner Version auffällt, ist etwas, was ich auch mache, aber sonst niemals bei irgend jemandem sehe und daher als gutes Indiz nutzen kann, auf einen Blick zu erkennen, welcher Code von mir ist und welcher nicht: INTO vor FROM. Nach meinem Dafürhalten war das einst bei SQL sogar so vorgeschrieben, jedenfalls bei Informix 4GL war diese Reihenfolge Pflicht. In ABAP schreibt aber sonst jeder zuerst FROM und danach erst INTO. ABAP akzeptiert beides.
Ganz ehrlich: Dein obenstehendes Beispiel finde ich optisch scheußlich. Das fängt schon damit an, dass "age" in einer neuen Zeile steht und damit optisch komplett vom Methodenaufruf losgelöst ist (während zugleich der Block eine Zeile länger wird).tar hat geschrieben: ↑21.10.2024 01:30Das hat mit einer konsistenten Formatierungsausrichtung zu tun, die in vielen gängigen Programmiersprachen so festgelegt ist, dass Unterbestandteile grundsätzlich einen Tabstopp eingerückt werden und vor allem, dass deren Abschluss wieder am Zeilenbeginn der übergeordneten Struktur endet. Beispiel:
Code: Alles auswählen.
data(lo_person) = new lcl_person( age = 43 gender = c_male name = value #( first = |Archibald| last = |Tuttle| ) ).
Code: Alles auswählen.
data(lo_person) = new lcl_person( age = 43
gender = c_male
name = value #( first = |Archibald|
last = |Tuttle| ) ).
Der macht es ja noch schlimmer: der packt den Methodenaufruf in eine Zeile, dann das Schlüsselwort EXPORTING in eine weitere Zeile und dann den nächsten Parameter in wieder eine weitere Zeile. Das ist komplett unnötig und liest sich miserabel. Aufruf, EXPORTING-Schlüsselwort und der erste Parameter können problemlos in einer Zeile stehen und etwaige weitere Parameter dann bündig unter dem ersten. Übersichtlicher geht es nicht, und zugleich braucht man weniger Zeilen dafür und hat so mehr auf dem Bildschirm.tar hat geschrieben:was - wo ich dir zustimme - der Pretty Printer leider nicht berücksichtigt, wobei es dann aber wieder doof aussähe, wenn es bspw. bei Importing mit 1 Parameter direkt dahinter und zusätzlich bei Exporting mit 3 Parametern unten drunter stünde.
Falsch. Den Schlüssel Deiner internen Tabelle siehst Du nicht in der Datenbanktabelle, sondern in der Typdefinition Deiner internen Tabelle!. Selbst wenn Du faul bist und Deine interne Tabelle einfach über die DB-Tabelle definierst, statt Dir die Mühe zu machen, in der Typdefinition diejenigen Spalten aufzuzählen, die Du in Deiner Routine tatsächlich brauchst (das sind fast nie alle), kannst Du immer noch schreiben:tar hat geschrieben:Du kannst das doch halten, wie du magst. Du siehst aber generell nicht per se, welche Felder Teil des Primärschlüssels sind - immer erst nach dem Absprung in die DB-Tabelle
Code: Alles auswählen.
DATA interne_tabelle TYPE SORTED TABLE OF db_tabellenname WITH UNIQUE KEY feld1 feld2 feld3.
Code: Alles auswählen.
ASSIGN itab[ feld1 = x ] TO FIELD-SYMBOL(<whatever>).
ASSERT sy-subrc = 0.
Das sehe ich ganz deutlich anders. Was Du da machen willst, ist eine Erweiterung der eh schon überflüssigen ungarischen Notation. Interne Tabellen sollten klar verständlich typisiert sein. Den Schlüssel an den Anfang der Tabelle zu stellen ist dabei eine gute Idee, und inder Mitte der Tabelle versteckte "ID"-Spalten eine gruselige Alternative (auch wenn Du so erreichst, dass sie alle hintereinander stehen, weil sie alle mit ID anfangen. Das heißt immer noch nicht, dass sie dann in der richtigen Reihenfolge (wie im Schlüssel) hintereinander stehen, 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!tar hat geschrieben:Es ist ohnehin sinnvoll, die Schlüssel ordentlicher zu benennen, bspw. bei klaren Entitäten eben einfach "ID", da es vollkommener Irrsinn wäre, jedesmal erst die Struktur anschauen zu müssen