Deklaration von Variablen

Deklaration von Variablen

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

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

Re: Deklaration von Variablen

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

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

Re: Deklaration von Variablen

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

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

@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

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