Deklaration von Variablen

Getting started ... Alles für einen gelungenen Start.
21 Beiträge Seite 1 von 2 (current) Nächste
21 Beiträge Seite 1 von 2 (current) Nächste

Deklaration von Variablen

Beitrag von Sebastian82 (ForumUser / 20 / 4 / 0 ) » 6. Feb 2019 16:25

Hallo zusammen,

als Abap Neuling habe ich mal eine Frage an die alten Hasen hier in der Runde.

Ich programmiere seit fast 20 Jahren in Sprachen wie Java oder C#. Dort ist es üblich und auch allgemein empfohlen, Variablen dort zu deklarieren wo sie genutzt werden. Das erhöht die Sicherheit durch den beschränkteren Geltungsbereich und führt auch zu einer höheren Lesbarkeit.

In Abap erlebe ich es aber immer wieder, dass alle Variablen die jemals benötigt werden direkt im Kopf deklariert werden. Dort stehen dann 20 oder 30 oder gar 50 Zeilen Code mit Variablen die erst 1000 Zeilen später gebraucht werden. Und ich frage mich, welchen Sinn das ergibt die Variable auf diese Art und Weise zu deklarieren?

Viele Grüße,

Sebastian


Re: Deklaration von Variablen

Beitrag von DeathAndPain (Top Expert / 1070 / 123 / 234 ) » 6. Feb 2019 16:40

Solche globalen Variablen sind üblicherweise schlechter Programmierstil. Variablen sollten i.d.R. am Anfang des jeweiligen Unterprogramms deklariert werden (Formroutine, Methode, Funktionsbaustein). Seit 7.40 gibt es auch die Möglichkeit der Inline-Deklaration, die man jedoch nur bei sehr lokal genutzten Variablen nutzen sollte, weil das sonst kein Schwein mehr überblickt.

Beachte aber, dass:

o Du für Dynpros zwingend globale Variablen brauchst, da Dynprofelder nur damit ansteuerbar sind
o die Attribute von Klassen vom Gebrauch her letztlich (klassen-)globalen Variablen entsprechen, so dass das angeblich so moderne OO hier einen programmiertechnischen Zombie zu neuem Leben erweckt hat. Die eine Methode schreibt irgendwas in das Attribut rein, eine andere liest es, und wer sich letztere Methode anschaut, hat keine Ahnung, wo der Inhalt des Attributes herkommt, da der Wert nicht Bestandteil des Methodeninterfaces ist.

Re: Deklaration von Variablen

Beitrag von nickname8 (Specialist / 106 / 15 / 16 ) » 6. Feb 2019 16:46

Ich glaube jemanden, der seit 20 Jahren Java oder C# programmiert, machst du keine Angst mit Attributen/Feldern/Klassenglobalen Variablen. :D

Re: Deklaration von Variablen

Beitrag von DeathAndPain (Top Expert / 1070 / 123 / 234 ) » 6. Feb 2019 17:13

Ich will ja auch niemandem Angst machen. Die Frage, wie sinnvoll globale Variablen sind, hat er ja letztlich selber aufgeworfen, sie ist Gegenstand seiner Frage.

Re: Deklaration von Variablen

Beitrag von ewx (Top Expert / 4000 / 165 / 378 ) » 6. Feb 2019 17:40

Im ABAP war das einfach so, dass die Datendeklaration an den Anfang gehörte.
Irgendwann gab es mal eine (oder zwei) Diskussion(en), ob es "schön" ist, sie auch zwischendrin zu machen. Nämlich erst dann, wenn sie verwendet wurden.
Mit Einführung der Inline-Datendeklaration ist das der neue Programmierstil.

Ich setze Variablen auch immer an den Anfang eines Moduls.
Fast immer. Bei der Entwicklung eines neuen Programms mache ich das häufig anders, denn das erleichtert später das refactoring, weil ich alles zusammen habe, was ich für die jeweilige Operation benötige.

Wenn am Anfang eines Reports 50 Zeilen nur Datendeklarationen stehen, ist es nicht das Problem, dass sie am Anfang stehen, sondern, dass sie global sind... ;)

Re: Deklaration von Variablen

Beitrag von ralf.wenzel (Top Expert / 3420 / 150 / 221 ) » 6. Feb 2019 17:45

Direkt Bezug nehmend auf DAP:

Also, zunächst einmal ist eine Klasse normalerweise deutlich übersichtlicher als eine monolithische Applikation. Ich erinnere mich da an RFZALI01, ein furchtbares Ding. Zudem ist ein Attribut nicht einfach nur eine Varible, sondern eine Variable mit einem semantischen Kontext, die den Zustand des Objektes beschreibt (alles andere gehört nicht in ein Attribut), während ich schon diverse Hilfsfelder als globale Variablen gesehen habe. Und schlussendlich kann man die Sichtbarkeit von Attributen auch noch ändern.

Insofern kann man globale Variablen in einem Koloss wie MEDRUCK nicht vergleichen mit einer Klasse, die einen eng umrissenen Umfang hat.


Ralf

Re: Deklaration von Variablen

Beitrag von deejey (Specialist / 217 / 58 / 17 ) » 6. Feb 2019 17:54

Den eng umrissenen Umfang und die Übersichtlichkeit und Nachvollziehbarkeit von Klassen kann man gut an ME22N sehen, ganz zu schweigen vom Debugging, geht locker von der Hand

edit
ok, falscher Thread :D

Re: Deklaration von Variablen

Beitrag von ralf.wenzel (Top Expert / 3420 / 150 / 221 ) » 6. Feb 2019 18:01

Wenn man das Beziehungsgeflecht verstanden hat, sind die Klassen dieser Transaktion deutlich übersichtlicher als man vorher meint.


Ralf

Re: Deklaration von Variablen

Beitrag von DeathAndPain (Top Expert / 1070 / 123 / 234 ) » 6. Feb 2019 18:18

ewx hat geschrieben:Wenn am Anfang eines Reports 50 Zeilen nur Datendeklarationen stehen, ist es nicht das Problem, dass sie am Anfang stehen, sondern, dass sie global sind...
Das ist der Knackpunkt, auf den ich auch hinaus will. Die Deklarationen von Feldern, die in der ganzen Subroutine gebraucht werden, am Anfang der Subroutine alle ordentlich beieinander stehen zu haben, ist kein Problem. Inline-Deklarationen sind nützlich, wenn sie tatsächlich lokal sind, ansonsten aber verwirrend und abzulehnen (womit ich mich meines Wissens auf offizieller SAP-Linie befinde).
Ralf hat geschrieben:Zudem ist ein Attribut nicht einfach nur eine Varible, sondern eine Variable mit einem semantischen Kontext, die den Zustand des Objektes beschreibt
Das ist eine rein ideologische Behauptung. Jede Variable hat eine Bedeutung, also einen semantischen Kontext, wofür sie steht und wofür sie verwendet wird (wobei ich bereit bin, Dir die Ausnahme rein lokaler Hilfsvariablen zuzugestehen. Zum Glück braucht man diese dank der neuen 7.40-Syntax fast gar nicht mehr). Eine gute Variable hat einen sprechenden Namen, der ihre Bedeutung ausdrückt (und bei dem ich schon oft genug gegen die heute nicht mehr zeitgemäße 30-Zeichen-Grenze gelaufen bin).
Ralf hat geschrieben:Und schlussendlich kann man die Sichtbarkeit von Attributen auch noch ändern.
Das ist ja das Schlimmste daran: In dem Moment, in dem ich ein Attribut auf "private" stelle, fällt auch noch seine Eigenschaft weg, das Objekt von außen sichtbar zu charakterisieren. Dann ist es wirklich nichts anderes mehr als eine globale Variable innerhalb der Klasse.

Und wenn man sich anschaut, wie Klassenattribute deklariert werden, wenn man es nicht in der SE24 macht (also bei programmlokalen Klassen oder bei DDIC-Klassen, die man in Eclipse pflegt), dann wird ja auch syntaktisch deutlich, dass ein Attribut nichts anderes ist als ein DATA-Befehl außerhalb einer Subroutine. Mit anderen Worten, ein globaler DATA.
Ralf hat geschrieben:Insofern kann man globale Variablen in einem Koloss wie MEDRUCK nicht vergleichen mit einer Klasse, die einen eng umrissenen Umfang hat.
Das tue ich auch nicht; das ist extrem ausgedrückt. Ich kann das gegenteilige Extrem dagegensetzen: Man kann globale Variablen ("Attribute") in einer riesigen Klasse, die von vielen Methoden der Klasse nach Gusto verändert werden und wo keiner mehr durchschaut, wo ihre Werte herkommen, nicht vergleichen mit einem kleinen Report, der eine globale interne Tabelle M mit Materialien hat, für die er nacheinander in einer Reihe von Unterprogrammen die Werte aus MARC, MARD usw. zusammensucht, ohne sich die Mühe zu machen, die Tabelle jedesmal als Parameter zu übergeben, und am Ende, wenn die Tabelle komplett gefüllt ist, gibt er sie als ALV aus. Ein solcher Report wäre problemlos nachvollziehbar; die Globalität dieser Tabelle wäre kein praktisches Problem dabei.

Fair ist weder Dein Vergleich noch der meinige, weil jeweils Extreme verglichen werden. Sehr wohl vergleichbar ist aber das Grundprinzip, nämlich das Werte, die codeglobal sind und daher ohne Schnittstelle von einem Teil des Codes zum anderen übergeben werden, das Prinzip der Kapselung verletzen und zu einem schlecht verständlichen, schlecht wartbaren und fehleranfälligen Code führen. Das gilt hier wie dort gleichermaßen.

Es ist durchaus auch nicht unüblich, Attribute nur per GET/SET-Methode zu setzen bzw. auszulesen. Böse Zungen könnten die zwar mit dem guten alten EXPORT TO MEMORY-Befehl vergleichen, aber sparsam und nachvollziehbar eingesetzt kann man damit das Ziel verfolgen, einem Objekt öffentliche Attribute zu verleihen, in denen es seinen Zustand speichert. Das Hauptproblem ist, dass diese Attribute eben in der ganzen Klasse von jedem Unterprogramm nach Belieben gelesen und manipuliert werden können, eben weil sie bei Licht betrachtet nichts anderes sind als klassenglobale Variablen. Während ein sauberer prozeduraler Programmierer globale Variablen höchstens noch als Report-Selektionsparameter oder zur Dynproansteuerung braucht, kommt man in OO nicht darum herum, sobald man das typische OO-Element der Attribute nutzen möchte. Das hätte man anders lösen müssen, etwa indem man zwischen normalen Methoden und "Attributmethoden" unterscheidet und nur letzteren Zugang zu dem Attribut gewährt, für das sie Attributmethode sind.

Re: Deklaration von Variablen

Beitrag von msfox (ForumUser / 49 / 6 / 5 ) » 6. Feb 2019 18:28

Sebastian82 hat geschrieben:In Abap erlebe ich es aber immer wieder, dass alle Variablen die jemals benötigt werden direkt im Kopf deklariert werden.
Meinst du damit am Anfang einer FORM-Routine / Methode oder als globale Variable bzw. Membervariable?

Globale Variablen haben ab und an ihren Sinn. Macht man ja in Java auch bei den Klassen. Wenn man nun die Funktionsgruppe als Klasse betrachtet und die darin enthaltenen FORM-Routinen als Methoden, sind in Funktionsgruppen die globalen Variablen quasi die Membervariablen. Soweit aus dieser Sicht.

Warum man allerdings am Anfang z.B. einer Routine immer alle Variablen deklariert ist Geschmacksache. Als ich aus der Java-Welt zu ABAP kam, habe ich mich das auch gefragt. Im BC-400 Lehrgang meinte man, dass während der Laufzeit zunächst alle Variablen im Code gesucht und an den Anfange gestellt werden.
Vielleicht war das in den Anfängen nicht so und führte dort vielleicht zu Performanceproblemen bei der "Umsortierung" des Codes.

Ich deklariere Variable auch manchmal mitten drin. Dann sind aber Kollegen der Meinung, sie müssen dies aufräumen.
Seit dem es aber die Inlinedeklarationn gibt, ist es nicht so einfach möglich, die Variablen einfach mal an den Anfang zu schieben.
Was den Kollegen dann wurmt :-).
Ein Vorteil fällt mir noch ein. Wenn man Variablen am Anfang deklariert und diese dort auskommentiert, findet man schneller raus, welche Variablen verwendet und welche nicht. Gut, geht auch mit dem Code-Inspektor, der vielleicht früher sich so umfänglich war.

Kurz: Aus meiner Sicht hat dies historische Gründe.

Re: Deklaration von Variablen

Beitrag von msfox (ForumUser / 49 / 6 / 5 ) » 6. Feb 2019 18:36

DeathAndPain hat geschrieben:Es ist durchaus auch nicht unüblich, Attribute nur per GET/SET-Methode zu setzen bzw. auszulesen. Böse Zungen könnten die zwar mit dem guten alten EXPORT TO MEMORY-Befehl vergleichen,
Im Java ist dies eher üblich*. Man hat eine Klasse mit PRIVATE-Variablen und hat dazu GETTER und SETTER. Die kann man in Eclipse reicht einfach generieren lassen.
Das Feature vermisse ich in der SE80 häufig.
*nicht unüblich: zweimal negiert ist auch positiv - also = üblich :-).

Re: Deklaration von Variablen

Beitrag von DeathAndPain (Top Expert / 1070 / 123 / 234 ) » 6. Feb 2019 18:44

Wenn man nun die Funktionsgruppe als Klasse betrachtet und die darin enthaltenen FORM-Routinen als Methoden, sind in Funktionsgruppen die globalen Variablen quasi die Membervariablen.
Oha, lass das nicht Ralf hören, dass Du gleichfalls der Ansicht bist, dass man Funktionsgruppen als (eine einfache Form von) Klassen ansehen kann und ihre globalen Variablen als Attribute. Der reißt Dir dafür den Kopf ab! :D
Ich deklariere Variable auch manchmal mitten drin. Dann sind aber Kollegen der Meinung, sie müssen dies aufräumen.
Gegenfrage: Warum deklarierst Du Methoden nicht mitten in irgendeinem Implementierungsteil einer anderen Methode, halt da, wo Du erstere Methode zum ersten Mal aufrufst?

Weil es chaotisch ist, Deklarationen und Implementierungen zu durchmischen. Ich finde es zwar Overkill, dass es bei Methoden überhaupt nötig ist, Deklaration und Implementierung zu trennen (Formroutinen zeigen, dass es auch ohne solch Trennung geht, und zwar sogar besser, weil man dort, wo man implementiert, auf einen Blick die Schnittstelle sieht und ggf. auch anpassen kann), aber wenn man es trennt, dann sollte man es schon auch sauber tun. Für Variablen gilt dasselbe. Wenn man man für einen LOOP ein Zielfeldsymbol braucht, das man innerhalb des LOOPs verwendet und sonst nicht mehr, dann ist es gut les- und nachvollziehbar, wenn man das direkt beim LOOP-Befehl per ASSIGNING FIELD-SYMBOL tut. Wenn man aber eine Variable quer durch den ganzen Code braucht, dann ist es sehr mies, sie mitten im Code per DATA() zu deklarieren, besonders wenn der Leser dann erst mal grübeln muss, welchen Datentyp sich dieser Data denn jetzt zieht. Eine rein lokale Inlinedeklaration mit DATA(), z.B. wenn man rasch mal ein Hilfsfeld braucht, um etwas zu berechnen oder um den Exportparameter eines PERFORM zu versorgen, ist hingegen in Ordnung.

Überdies läuft eine Inline-Deklaration per DATA() oft inhaltlich auf ein LIKE LINE OF hinaus, wenn man sich damit eine Workarea zieht. Und ein LIKE LINE OF ist bedeutend verständlicher, wenn es direkt unter der Deklaration der internen Tabelle steht, auf die es sich bezieht.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag (Insgesamt 2):
Danielblack_adept


Re: Deklaration von Variablen

Beitrag von ralf.wenzel (Top Expert / 3420 / 150 / 221 ) » 6. Feb 2019 18:50

@DAP:

Schon das Wort „Attribut“ zeigt an, dass es eine Eigenschaft des Objektes beschreibt, was weit mehr ist als viele Variablen tun. Natürlich kann man jeden Dreck in ein Attribut packen, aber das ist halt nicht der Sinn eines Attributes. Und warum ein privates Attribut einfach eine globale Variable sein soll, erschließt sich mir nicht. Ich habe den Eindruck, du weißt gar nicht, warum man Attribute als protected oder private deklariert. Das hat was mit Objektkonsistenz zu tun.

Ich arbeite fast nie mit öffentlichen Attributen, damit das Objekt kontrollieren kann, ob es sich überhaupt um einen gültigen Wert handelt.


Ralf

Re: Deklaration von Variablen

Beitrag von ralf.wenzel (Top Expert / 3420 / 150 / 221 ) » 6. Feb 2019 18:59

DeathAndPain hat geschrieben:
Wenn man nun die Funktionsgruppe als Klasse betrachtet und die darin enthaltenen FORM-Routinen als Methoden, sind in Funktionsgruppen die globalen Variablen quasi die Membervariablen.
Oha, lass das nicht Ralf hören, dass Du gleichfalls der Ansicht bist, dass man Funktionsgruppen als (eine einfache Form von) Klassen ansehen kann und ihre globalen Variablen als Attribute. Der reißt Dir dafür den Kopf ab! :D
Quatsch, ich reiße Leuten höchstens den Kopf ab, wenn sie für mich programmieren und dabei Murks machen.

Eine Funktionsgruppe ist schon deshalb nicht eine Klasse, weil ihr entscheidende Eigenschaften fehlen, die eine Klasse per Definition hat. Wahr ist: Beides sind Programm-Module. Aber eine Funktionsgruppe beschreibt kein Geschäftsobjekt (z. B. einen Beleg), das kann sie auch gar nicht, weil ich sie nicht instanziieren kann. Das ist aber das Wesen einer Klasse. Und weil eine FG kein Geschäftsobjekt beschreiben kann, kann es auch nicht den Zustand dieses Geschäftsobjektes beschreiben. Das wiederum zeigt, warum Funktionsgruppen-globale Variablen nicht dasselbe sind wie zustandsbeschreibende Attribute.

Ein Kettcar wird nicht deshalb zu einem vereinfachten Auto, weil es vier Räder hat.


Ralf

Re: Deklaration von Variablen

Beitrag von Daniel (Specialist / 313 / 67 / 43 ) » 6. Feb 2019 19:22

DeathAndPain hat geschrieben:Wenn man man für einen LOOP ein Zielfeldsymbol braucht, das man innerhalb des LOOPs verwendet und sonst nicht mehr, dann ist es gut les- und nachvollziehbar, wenn man das direkt beim LOOP-Befehl per ASSIGNING FIELD-SYMBOL tut.
Bis dahin: Ja.
Nur ist das Feldsymbol von da an für den Rest des Programms
(in der Reihenfolge des Codings) gültig. Das ist Murks.
Verwendet man es wieder (weil man die Tabelle öfter braucht)
ist es eimal inline und x-mal extern definiert. So liebe ich das :x .
Und wehe wenn jetzt jemand eine Routine oder ein Include
umhängt. Wer das erfunden hat gehört gesteinigt!
Richtig gemacht wäre es wenn das Feldsymbol nur während des
Loops gültig ist.
DeathAndPain hat geschrieben:Eine rein lokale Inlinedeklaration mit DATA(), z.B. wenn man rasch mal ein Hilfsfeld braucht, um etwas zu berechnen oder um den Exportparameter eines PERFORM zu versorgen, ist hingegen in Ordnung.
Ich schätze das nicht besonders, aber wenn man damit sparsam
umgeht mag es ok sein.
DeathAndPain hat geschrieben:Überdies läuft eine Inline-Deklaration per DATA() oft inhaltlich auf ein LIKE LINE OF hinaus, wenn man sich damit eine Workarea zieht. Und ein LIKE LINE OF ist bedeutend verständlicher, wenn es direkt unter der Deklaration der internen Tabelle steht, auf die es sich bezieht.
Ja, absolut!
Gerade in ABAP ist Lesbarkeit und Verständlichkeit das Wichtigste.
Diese Programme werden oft steinalt, zig mal erweitert und von
vielen Entwicklern betreut. Der Zeitaufwand der da verplempert
wird weil Coding unübersichtlich und unverständlich ist geht in
Größenordnungen die eine komplette Neuentwicklung bei weitem
überschreiten.

Folgende Benutzer bedankten sich beim Autor Daniel für den Beitrag:
black_adept


Seite 1 von 2 (current) Nächste

Aktuelle Forenbeiträge

Workflow: eMail Versand
vor 4 Stunden von SaskuAc 3 / 53
Speichern von Eingabe des Selektionscreens
vor 15 Stunden von black_adept 3 / 68
Join über mehrere Tabellen sehr langsam
vor 22 Stunden von Daniel 2 / 91
Ermittlung interner/externer Mitarbeiter
Gestern von deejey 3 / 153
Excel OLE2 Blatt schützen gelöst
Gestern von Kerstin 5 / 73

Unbeantwortete Forenbeiträge

SP01 Verweildauer
vor 6 Tagen von SAP_ENTWICKLER 1 / 89
Transaktion OMT3B Subscreens in Dynpros einhängen
vor einer Woche von SAP_ENTWICKLER 1 / 62
Zeitereignisarten anlegen
vor 2 Wochen von Flashtie 1 / 174
Genehmiger & Status der Genehmigung bei einer BANF
vor 3 Wochen von Der Formulator 1 / 245
Migrationstool Upload QUAN und CURR Felder
vor 3 Wochen von SAP_ENTWICKLER 1 / 231