Method für die Durchschnittsberechnung

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

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

Method für die Durchschnittsberechnung

Beitrag von msentaburlar (ForumUser / 16 / 2 / 0 ) »
Hallo,


ich habe ein Problem mit dem Abap Obejct und zwar ich habe schon eine Method erstellt, die interne Tabelle mit dem erzeugten Objekten füllt. Ich muss jetzt noch eine andere Method erstellen, die Durchschnittsalter von den Objekten berechnen soll.

Kann jemand mit Tipp geben?

Viele Grüße
msentaburlar

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


Re: Method für die Durchschnittsberechnung

Beitrag von jocoder (Specialist / 338 / 3 / 101 ) »
Code posten wäre hilfreich. Ohne den Code können wir nur raten.

Folgende Benutzer bedankten sich beim Autor jocoder für den Beitrag:
DeathAndPain


Re: Method für die Durchschnittsberechnung

Beitrag von SaskuAc (Specialist / 321 / 37 / 43 ) »
schließe mich jocoder an, code wäre sehr hilfreich. ansonsten hier mal ne kurze möglichkeit....

Code: Alles auswählen.

methods: berechne_durchschnitt importing tabelle_mit_objekten type irgendwas returning value(durchschnitts_alter) type i.
method berechne_durchschnitt.
data(gesamt_alter) = 0.
loop at tabelle_mit_objekten into data(objekt). 
    gesamt_alter = gesamt_alter + objekt-alter.
endloop.

durchschnitts_alter = gesamt_alter / lines( tabelle_mit_objekten ).

endmethod. 
mehr können wir dir hier auch nicht sagen. Weil wir ja sonst keine weiteren infos haben... und wahrscheinlich ist es in dem fall nicht so einfach wie hier ....

Folgende Benutzer bedankten sich beim Autor SaskuAc für den Beitrag:
msentaburlar


Re: Method für die Durchschnittsberechnung

Beitrag von msentaburlar (ForumUser / 16 / 2 / 0 ) »
Hallo,

ich bedanke mich bei euch erstmal für eure Rückmeldung. Ich glaube diese Beispiel-Code sehr hilfreich für mich. Falls ich was noch brauche, dann füge ich noch mal hier mein Code.

Viele Grüße

msentaburlar

Re: Method für die Durchschnittsberechnung

Beitrag von msentaburlar (ForumUser / 16 / 2 / 0 ) »
Hallo,

ich wollte hier auch mitteilen, dass das Problem gelöst wurde.

Viele Grüße

msentaburlar

Re: Method für die Durchschnittsberechnung

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »

Code: Alles auswählen.

data(gesamt_alter) = 0.
@SaskuAc: Diese Inline-Deklaration kommt mir sehr unmotiviert vor. Sie steht am Anfang der Methode, und das = 0 schreibst Du nur, um das zu erreichen, was Du eigentlich willst, nämlich ABAP zu motivieren, das als Integer zu typisieren. Warum nicht einfach

Code: Alles auswählen.

data gesamt_alter TYPE I.
Das würde ich an dieser Stelle bedeutend schöner finden - und ein DATA in einer Unterroutine führt immer zur Initialisierung des Objektes (also zur Nullsetzung) bei jedem Aufruf.

Re: Method für die Durchschnittsberechnung

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
DeathAndPain hat geschrieben:
16.01.2020 08:56
[...] und das = 0 schreibst Du nur, um das zu erreichen, was Du eigentlich willst[...]
Das mache ich eigentlich mit jedem Befehl... 🤪

Ich finde diese Schreibweise super, denn sie fördert genau das, was häufig von vielen als unschön oder sogar nervig angesehen wird, nämlich ein Packen von Data-Anweisungen zu Beginn einer Funktion.

Ja, "DATA(x) = 1" macht das gleiche wie "DATA x TYPE i VALUE 1". Die erste Variante kann ich aber aber als Anweisung in den Programmablauf einfließen lassen. Die zweite Variante ist eine Deklaration, bei der ich es sehr unschön finde, wenn ich diese im Programmablauf finde.

Die Variante mit Inline-Deklaration wird auch im SAP Styleguide angeraten.

Re: Method für die Durchschnittsberechnung

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
ewx hat geschrieben:
16.01.2020 09:27
DeathAndPain hat geschrieben:
16.01.2020 08:56
[...] und das = 0 schreibst Du nur, um das zu erreichen, was Du eigentlich willst[...]
Das mache ich eigentlich mit jedem Befehl... 🤪
Aber genau das sollte der Befehl auch ausdrücken, was er bei dieser Inline-Deklaration eben nicht tut.
Ich finde diese Schreibweise super, denn sie fördert genau das, was häufig von vielen als unschön oder sogar nervig angesehen wird
Also willst Du die Leute ärgern? 😉
, nämlich ein Packen von Data-Anweisungen zu Beginn einer Funktion.
Da kann man geteilter Meinung darüber sein, ob das schön oder unschön ist. Ich finde es richtig und wichtig bei Feldern, die, sagen wir mal, "routinenglobal" sind, also in einer (größeren) Unterroutine immer wieder benötigt werden. Inline-Deklarationen hingegen sollten streng lokal verwendet werden, also nicht irgendwann weiter unten im Code nochmal.

Und bitte jetzt nicht das Argument, dass alle Methoden nur 10 Zeilen lang sein sollten, so dass alles als lokal einzustufen ist. Dieses Paradigma halte ich für ebenso gutaussehend wie praxisuntauglich, denn es führt dazu, dass Fremdcode kaum mehr nachvollziehbar ist - obwohl es paradoxerweise genau das Gegenteil erreichen soll! Hintergrund ist, dass eine Unterroutine eine ähnliche Bedeutung hat wie ein selbst definierter Befehl. Die normalen ABAP-Befehle kennt jeder. Wenn da also 10 Zeilen normalen Codes stehen, kannst Du den normalerweise lesen und interpretieren. Wenn der Code aber nur aus Aufrufen irgendwelcher Unterroutinen besteht, die selber wieder aus Aufrufen bestehen, und das Ganze so weit runter, bis Du auf der Ebene, wo echter Code steht, keinen Kontext mehr siehst, dann ist das im Prinzip, also würdest Du eine Programmiersprache lesen, die Du nicht kennst (und die möglicherweise sogar Bugs enthält (jenseits von dem, was produktiv genutzte Programmiersprachen an Rest-Bugs zu haben pflegen)). Deswegen bin ich der Meinung, dass es sinnvoll ist, seinen Code in sinnvolle Verarbeitungsblöcke zu gliedern, diese als Unterroutinen auszuführen - und jede einzelne davon mit einem ausführlichen Textkommentar am Kopf der Routine zu versehen, der erläutert, was diese Routine genau macht und was rein- und rausgeht.

Wenn man aber jeden kleinen 5-Zeiler dieserart kapselt, ist das nicht mehr praktikabel, und man erreicht das Gegenteil von dem, was man erreichen möchte. Davon abgesehen hat Otto Normalprogrammierer ja noch nicht einmal die Disziplin, seine normalen Routinen mit einem anständigen Kopfkommentar zu versehen (selbst Klassen, öffentlichen Methoden und Funktionsbausteine sind ja erschreckend oft ohne jede Online-Doku). Da ist es realitätsfernes Wunschdenken anzunehmen, dass die Leute jedem mutwillig untergekapselten Fünfzeiler eine eigene Doku zukommen lassen, damit man beim Sichten der Aufrufstelle versteht, was dieser Aufruf genau tut. Aber selbst, wenn sie es täten, ist bei einer derart feinen Granulierung das Programm unübersichtlich, wenn man nur Aufrufstellen und zugehörigen Kommentartext (der hoffentlich stimmt und ausführlich genug ist) liest anstelle von echtem Code, bei dem man "sieht", was er macht.
Ja, "DATA(x) = 1" macht das gleiche wie "DATA x TYPE i VALUE 1". Die erste Variante kann ich aber aber als Anweisung in den Programmablauf einfließen lassen. Die zweite Variante ist eine Deklaration, bei der ich es sehr unschön finde, wenn ich diese im Programmablauf finde.
Und im vorliegenden Beispiel ist sie nicht "im Programmablauf", sondern am Beginn der Methode. Dort, an der typischen Stelle für Deklarationen, Inline-Deklarationen zu bringen, macht m.E. wenig Sinn. Dafür sind Inline-Deklarationen nicht gedacht. Genau das war mein Kritikpunkt.
Die Variante mit Inline-Deklaration wird auch im SAP Styleguide angeraten.
Die SAP empfiehlt aber auch analog zu dem, was ich oben geschrieben habe, Inline-Deklarationen streng lokal zu verwenden und eben nicht die normalen Deklarationen durch Inlines zu ersetzen.

Ich bin der erste, der das neue ASSIGNING FIELD-SYMBOL() zu schätzen weiß und es nicht vermisst, irgendwo weit oben im Code ein separates FIELD-SYMBOLS schreiben zu müssen. Ich bin sogar so inkonsequent, das zu machen, wenn ich im weiteren Verlauf nochmal über dieselbe Tabelle loopen muss und dafür das dieserart inline deklarierte Feldsymbol recycle. Allerdings mache ich das in einer Weise, bei der die Verständlichkeit dennoch nicht beeinträchtigt ist, da Feldsymbole in LOOPs für mich in ihrer Funktion als Workarea-Ersatz gleichnamig zu den geloopten Tabellen sind (und damit hervorragend die alten Kopfzeilen ersetzen).

Aber normale Felddeklarationen am Anfang der Routine durch Inlines ersetzen? Ne.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Legxis


Re: Method für die Durchschnittsberechnung

Beitrag von jocoder (Specialist / 338 / 3 / 101 ) »
Und bitte jetzt nicht das Argument, dass alle Methoden nur 10 Zeilen lang sein sollten, so dass alles als lokal einzustufen ist. Dieses Paradigma halte ich für ebenso gutaussehend wie praxisuntauglich, denn es führt dazu, dass Fremdcode kaum mehr nachvollziehbar ist - obwohl es paradoxerweise genau das Gegenteil erreichen soll!
Zu deiner Meinung:
10 Zeilen lassen sich in Sprachen wie ABAP durch oft langen Befehle selten sinnvoll realisieren.
Ich finde eine vernüftige Länge ist erreicht, wenn die Prozedur nicht mehr auf eine Bildschirmseite passt oder zu viele Verzweigungen enthält.

Mit der Prozedurlänge sollte man es halten wie mit einem Aktenordner. Man heftet auch nicht seine ganze Zettelwirtschaft wild durcheinander in einem einzigen Ordner ab, bis der Deckel sich nicht mehr schließen lässt. Sondern man bildet auch hier auch Register oder mehrere Ordner und sortiert die Zettelwirtschaft thematisch. Naja wenn man jemals wieder was finden will 😊

Re: Method für die Durchschnittsberechnung

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Ja, aber bei der Bewertung der "richtigen" Prozedurlänge bin ich ein ganz großer Fan von "gesundem Menschenverstand" anstelle von "Anzahl Codezeilen" oder gar "Bildschirmseite" (die sieht bei Eclipse von der Zeilenzahl schon ganz anders aus als in der SE38, und über eine Veränderung der Fontgröße kriegt man da nochmal ganz andere Zeilen hin. Auch ist es Geschmacksache, wo man der Lesbarkeit halber Leerzeilen im Code einstreut, und in den Code eingebettete Kommentarzeilen können diesen auch schnell länger machen. Von daher sage ich: sinnvoll in Unterprogramme strukturieren, nicht irgendwelchen Faustformeln unterwerfen, die ohne Bezug auf die Programmieraufgabe, vor der man gerade steht, aufgestellt worden sind.

Wenn eine Prozedur aus mehreren, linear aufeinanderfolgenden und absehbar nirgendwo anders benötigten Schritten besteht, dann entschließe ich mich auch gerne mal dazu, diese Schritte nicht zu kapseln, sondern mit deutlich sichtbaren Kommentartrennlinien voneinander zu trennen. Dann sieht man als Leser, wie ein Schritt auf den anderen folgt und das Ganze dennoch eine Einheit bildet. Natürlich darf die Gesamtlänge dabei nicht völlig aus dem Ruder laufen.

Beispiel: Ich habe Daten aus einer Datenbanktabelle in eine interne Tabelle eingelesen, in einer Bildschirmmaske dargestellt und dem Nutzer Änderungen daran ermöglicht. Nachdem der irgendwas gemacht hat und auf "Sichern" klickt, will ich jetzt die Daten in der internen Tabelle in die Datenbank zurückschreiben, aber logischerweise nur den Teil, der sich tatsächlich verändert hat. Da Änderungen auch an Spalten stattgefunden haben können, die zum Primärschlüssel der Datenbanktabelle gehören (beispielsweise das Gültigkeitsende eines Datensatzes, das ist im HCM nicht unüblich, das mit in den Schlüssel zu packen), ist der Weg in solchen Fällen "Löschen und neu anlegen".

Dann besteht die Programmiertätigkeit für mich aus zwei Pässen: Pass 1 schaut, welche Datensätze es in der Datenbank gibt, in meiner internen Tabelle aber nicht mehr. Diese sind zu löschen. Pass 2 schaut, welche Datensätze ich in meiner internen Tabelle habe, die es auf der Datenbank (noch) nicht gibt. Diese sind anzulegen.

Nun könnte ich Folgendes machen (Parameter lasse ich an dieser Stelle mal weg):

Code: Alles auswählen.

FORM WRITE_DATA.

  PERFORM PASS1.
  PERFORM PASS2.

ENDFORM.
Und danach dann die Implementierungen von PASS1 und PASS2. Das finde ich aber affig; mit dieser Kapselung gewinnt man nicht wirklich viel. Da mache ich lieber:

Code: Alles auswählen.

FORM WRITE_DATA.

********** PASS 1 **********
"  Actual code of pass 1

********** PASS 2 **********
"  Actual code of pass 2

ENDFORM.
Auch wenn jeder der beiden Pässe 50 Zeilen Code lang ist.

Re: Method für die Durchschnittsberechnung

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
DeathAndPain hat geschrieben:
16.01.2020 12:09
Und danach dann die Implementierungen von PASS1 und PASS2. Das finde ich aber affig; mit dieser Kapselung gewinnt man nicht wirklich viel. Da mache ich lieber:[...]
Glücklicherweise darf hier jeder seine eigene Meinung haben... 🙃

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


Re: Method für die Durchschnittsberechnung

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Ja, jeder hat ein Recht auf meine Meinung. 😁

Re: Method für die Durchschnittsberechnung

Beitrag von SaskuAc (Specialist / 321 / 37 / 43 ) »
DeathAndPain hat geschrieben:
16.01.2020 12:09

Code: Alles auswählen.

FORM WRITE_DATA.

  PERFORM PASS1.
  PERFORM PASS2.

ENDFORM.
Und danach dann die Implementierungen von PASS1 und PASS2. Das finde ich aber affig; mit dieser Kapselung gewinnt man nicht wirklich viel. Da mache ich lieber:

Code: Alles auswählen.

FORM WRITE_DATA.

********** PASS 1 **********
"  Actual code of pass 1

********** PASS 2 **********
"  Actual code of pass 2

ENDFORM.
Auch wenn jeder der beiden Pässe 50 Zeilen Code lang ist.
Was du dadurch gewinnst? Wartbarkeit, lesbarkeit ( auch wenn du anderer meinung bist ) und erweiterbarkeit. ( und noch ein paar andere aspekte )

Wartbarkeit: Du musst dich nicht drum kümmern, was in pass2 passiert. pass1 muss funktionieren und fertig. Wenn in pass1 ein Fehler da ist musst du ihn nicht in der gesamten Routine suchen sondern eben nur in der einen Methode / form.

Lesbarkeit: Da du nur wissen musst was und eben nicht wie etwas in einer Methode, die du aufrufst, passiert, sollte dir der name ( in kombination mit dem wissen um die dazugehörige klasse ) genügen, um den code lesen zu können. Natürlich müssen dafür sprechende namen verwendet werden. Du weißt eben direkt was "write_data" macht, wenn pass1 und pass2 sprechende namen haben. Weil du eben auch direkt weißt was pass1 und pass2 machen..

Erweiterbarkeit: Wenn du in der gesamt-routine, in der du eben pass1 und pass2 aufrufst, eine prüfung einbauen möchtest, welche z. b. berechtigungen prüft, dann schreibst du zw. den Aufrufen von pass1 und pass2 ( oder an einen anderen ort in dieser routine ) den Aufruf "prüfe_berechtigung_für_pass2" - und bei bedarf kannst du das wieder raus nehmen. Dafür musst du aber nicht pass2 anfassen und evtl. etwas "kaputt machen".

Wenn man dann noch Unit-Tests schreibt, was meiner Meinung nach vorschrift sein sollte......, dann wäre die Wartbarkeit sogar durch diese modularisierung automatisiert. Denn du weißt direkt, wenn du etwas transportierst ( und die entsprechenden prüfungen aktiv sind ) ob etwas noch funktioniert wie es soll oder eben nicht. Wie sollte man sowas mit riesigen Routinen machen können?

Zum Thema größe der Routine... natürlich bin ich froh, wenn ich kleinere routinen finde, aber da bin ich der Meinung, dass dies abhängig ist von verschiedenen Faktoren. Pauschalaussagen, wie "max. 50 Zeilen" oder "max. eine Bildschirmlänge" finde ich persönlich auch schwachsinn. Persönlich entwickle ich mit Eclipse lieber mit hochkantem bildschirm als quer. Aber umso kürzer, desto besser, das ist mein Motto wenns um einzelne Routinen geht.

Finde es lustig, das so etwas kleines wie die deklaration von einer Variable so eine diskussion auslösen kann.
Ich entwickle in letzter Zeit ein wenig in JavaScript, und habe dort alle meine deklarationen in dem moment wenn ich sie brauche. Das mache ich in ABAP inzwischen genauso. ( ein hoch auf die inline deklaration! ) - nur habe ich es hier zu Anschauungszwecken direkt in der ersten Zeile gemacht und nicht erst bei der ersten Verwendung. Außerdem, hilft es den Leuten vielleicht mal ein wenig auf die neue Syntax umzusteigen, wenn man es direkt so macht... sehe viel zu viel davon, dass leute upfront deklarationen vornehmen, obwohl inline für 95% der Fälle ausreicht...



Naja... unterm Strich ists jedem seins, wie man es macht. Jedem seine Meinung. :)

Folgende Benutzer bedankten sich beim Autor SaskuAc für den Beitrag (Insgesamt 3):
ewxST22Legxis


Re: Method für die Durchschnittsberechnung

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Wartbarkeit: Du musst dich nicht drum kümmern, was in pass2 passiert.
Das muss ich auch so nicht. Die beiden Teile sind durch einen dicken Strich getrennt und insofern eigenständig. Höchstens könnte man argumentieren, dass ich durch die modulare Trennung jeweils nur die Felder deklarieren muss, die ich in dem betreffenden Pass brauche. Aber auch da ist mein Beispiel ein gutes, da ich in beiden Pässen weitestgehend die gleichen lokalen Felder und Tabellen benötige, so dass ich sogar Doppeldeklarationen spare. Die einzige theoretisch mögliche Wechselwirkung wäre ein vergessener CLEAR zwischen den Pässen. Aber der ist für mich kein ausreichendes Entscheidungskriterium.
Lesbarkeit: Da du nur wissen musst was und eben nicht wie etwas in einer Methode, die du aufrufst, passiert, sollte dir der name ( in kombination mit dem wissen um die dazugehörige klasse ) genügen, um den code lesen zu können.
Das ist eben die große Illusion, die oft auch als Vorteil von OO angeführt wird, die aber in der Praxis allenfalls dann gilt, wenn der Code aus Deiner eigenen Feder stammt. Bei anderen, bei denen Du zunächst noch nicht mal weißt, mit welchen programmiertechnischen Ideen sie an das Problem herangegangen sind, welche Soll-Werte die Datenstrukturen (bei denen es sich womöglich gar selber um Containerobjekte handelt) haben, vielleicht sogar noch nicht mal, was das Programm genau machen soll, da hilft Dir der Name einen Dreck. Konkreten Code kannst Du interpretieren, auch wenn das je nach Umständen nicht einfach ist, aber Namen von Unterroutinen? Vergiss es. Sie sind hilfreich, ja, aber nicht mal näherungsweise ausreichend. Nur exzellente Dokumentation von jeder einzelnen Unterroutine und jedem einzelnen Parameter würde helfen, aber das macht praktisch niemand.
Erweiterbarkeit: Wenn du in der gesamt-routine, in der du eben pass1 und pass2 aufrufst, eine prüfung einbauen möchtest, welche z. b. berechtigungen prüft, dann schreibst du zw. den Aufrufen von pass1 und pass2 ( oder an einen anderen ort in dieser routine ) den Aufruf "prüfe_berechtigung_für_pass2" - und bei bedarf kannst du das wieder raus nehmen. Dafür musst du aber nicht pass2 anfassen und evtl. etwas "kaputt machen".
Das muss ich auch so nicht. Da würde ich einfach schreiben:

Code: Alles auswählen.

FORM WRITE_DATA.

********** PASS 1 **********
"  Actual code of pass 1

********** Berechtigungsprüfung für PASS 2 **********
" Coding

********** PASS 2 **********
"  Actual code of pass 2

ENDFORM.
Der mittlere Block kann problemlos eingesetzt und wieder herausgenommen werden, ohne mit Pass 2 zu interferieren.
Wenn man dann noch Unit-Tests schreibt, was meiner Meinung nach vorschrift sein sollte......, dann wäre die Wartbarkeit sogar durch diese modularisierung automatisiert.
Das ist sie in meinem Fall auch. Die Frage ist halt, wie groß die Units sind. In diesem Falle ist die Frage, ob es Sinn macht, die Hälfte der Datensicherung zu testen und in einem anderen Test die andere Hälfte, oder ob es nicht doch besser ist zu sagen, ich habe eine Programmunit, die die Daten aus dem Arbeitsspeicher wieder in die Datenbank schreibt, und die teste ich.
Denn du weißt direkt, wenn du etwas transportierst ( und die entsprechenden prüfungen aktiv sind ) ob etwas noch funktioniert wie es soll oder eben nicht. Wie sollte man sowas mit riesigen Routinen machen können?
Wenn ich in Pass 1 etwas ändere, dann weiß ich genau so wie bei Dir, dass Pass 2 sich nicht verändert hat. Beides sind Codeblöcke, die für sich stehen und für sich funktionieren, aber nur in sequentieller Abarbeitung gemeinsam Sinn ergeben und daher eine semantische Einheit bilden.
Ich entwickle in letzter Zeit ein wenig in JavaScript, und habe dort alle meine deklarationen in dem moment wenn ich sie brauche. Das mache ich in ABAP inzwischen genauso. ( ein hoch auf die inline deklaration! ) - nur habe ich es hier zu Anschauungszwecken direkt in der ersten Zeile gemacht und nicht erst bei der ersten Verwendung. Außerdem, hilft es den Leuten vielleicht mal ein wenig auf die neue Syntax umzusteigen, wenn man es direkt so macht... sehe viel zu viel davon, dass leute upfront deklarationen vornehmen, obwohl inline für 95% der Fälle ausreicht...
Ich habe schon eine Menge Inline-Deklarationen gesehen, die die Verständlichkeit des Codes deutlich erschwert haben, weil man erst mal ins Grübeln gekommen ist, welcher Datentyp da jetzt eigentlich bei rauskommt. Man sieht das Feld irgendwo, macht einen Doppelklick darauf und landet nicht bei einer verständlichen Deklaration, sondern inmitten einer Codegrütze, die in einem völlig anderen Kontext steht, so dass man erst mal überlegen muss, was das für ein Feld sein soll. Deswegen empfiehlt die SAP ja, Inline-Deklarationen nur streng lokal anzuwenden, und meiner Meinung nach sollte man sich daran auch halten (mal abgesehen von dem trivialen Ausnahmefall, den ich in einer früheren Antwort geschildert habe).

Witzig auch, dass über Inline-Deklarationen die Deklaration dorthin geholt wird, wo das Feld tatsächlich gebraucht wird, während man zugleich mit der Einführung von OO das Gegenteil tut und die Schnittstellenbeschreibungen von Unterprogrammen ans andere Ende des Codes zwingt. IMHO einer der größten Nachteile von OO und in meinen Augen auch völlig unnötig. Ein Anpassungskotau gegenüber anderen Programmiersprachen, die es nicht besser können.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Legxis


Re: Method für die Durchschnittsberechnung

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
DeathAndPain hat geschrieben:
16.01.2020 15:49
Wartbarkeit: Du musst dich nicht drum kümmern, was in pass2 passiert.
Das muss ich auch so nicht. Die beiden Teile sind durch einen dicken Strich getrennt und insofern eigenständig.
Aber eben nur theoretisch. Du verwendest aber evtl. gleiche Variablen in Block A und B. Du kannst also mit einer Änderung in Block A das Verhalten von Block B verändern, ohne dass es dir bewusst ist!

Ein weiterer wichtiger Punkt, den ich bei kleinen Einheiten zu schätzen gelernt habe: Wenn du debuggen musst, dann musst du bei großen Code-Blöcken durch die meisten Anweisungen im Einzelschritt durch. Selbst wenn es nur drei Mal "F5" für drei Anweisungen ist anstatt ein Mal "F6" für die Funktion, die das gleiche tut, ist das im Stress und unter Zeitdruck eine enorme Hilfe. Ich finde es sehr hilfreich, wenn ich schnell über eine Funktion "hinweg-debuggen" kann, weil ich weiß, dass hier nichts Fehlerrelevantes passiert.

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
ST22


Vergleichbare Themen

2
Antw.
117
Views
method INTERNAL_ASSERT ????
von Anfänger » 20.12.2023 16:27 • Verfasst in ABAP® für Anfänger
3
Antw.
1499
Views
METHOD handle_user_command
von SAP_ENTWICKLER » 19.09.2013 09:38 • Verfasst in ABAP® Core
0
Antw.
1292
Views
Access Method 'G'
von slim » 02.03.2007 11:41 • Verfasst in Web Application Server
7
Antw.
4184
Views
FORM vs METHOD
von Dyrdek » 13.10.2016 12:20 • Verfasst in ABAP® für Anfänger
3
Antw.
2144
Views
method changing
von kostonstyle » 05.08.2008 10:28 • Verfasst in ABAP® für Anfänger

Über diesen Beitrag


Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

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.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 4 Tagen von Lucyalison 1 / 72
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141