Method für die Durchschnittsberechnung

Re: Method für die Durchschnittsberechnung

Code posten wäre hilfreich. Ohne den Code können wir nur raten.

Re: Method für die Durchschnittsberechnung

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

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

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.

Re: Method für die Durchschnittsberechnung

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):
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:
Auch wenn jeder der beiden Pässe 50 Zeilen Code lang ist.

Re: Method für die Durchschnittsberechnung

Ja, jeder hat ein Recht auf meine Meinung. 😁

Re: Method für die Durchschnittsberechnung

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