Führende Nullen löschen Thema ist als GELÖST markiert

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
23 Beiträge • Vorherige Seite 2 von 2 (current)
23 Beiträge Vorherige Seite 2 von 2 (current)

Re: Führende Nullen löschen

Beitrag von a-dead-trousers (Top Expert / 3458 / 106 / 894 ) » 01.07.2020 08:30
Weil wir eh schon OFF-Topic unterwegs sind möchte ich kurz was anmerken.
ralf.wenzel hat geschrieben:
30.06.2020 21:01
Dass Attribute etwas anderes sind als Variablen, doziere ich seit Jahr und Tag. Ich frage mich nur: Warum gibt es analog zum Pretty Printer keine Funktion, die zu jedem Attribut eine SET- und eine GET-Methode erzeugt? Warum muss ich sowas selbst schreiben (also eben diesen Generator)? Dann würde die Faulheit "ach, mach ich's halt public" nicht ständig siegen. Auf der anderen Seite muss man diese Entwickler auch fragen, ob sie so einen Murks in anderen Bereichen ihres Lebens dulden würden, wenn sie mit ihm konfrontiert würden.

In aller Regel ist es reine Faulheit, soweit ich das beobachten konnte.
Es ist leider nicht immer nur die Faulheit.
Viele ABAP-Befehle verstehen bis heute noch nicht mit einem Methodenaufruf umzugehen. Ein konkretes Beispiel ist die zwingende Verwendung von Variablen im SELECT-Befehl. "WHERE x = lr_object->get_filter_x( )" geht da nicht.

Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ralf.wenzel

Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.07
Basis: 7.40


Re: Führende Nullen löschen

Beitrag von black_adept (Top Expert / 3366 / 65 / 632 ) » 01.07.2020 09:11
ralf.wenzel hat geschrieben:
30.06.2020 21:01
Ich frage mich nur: Warum gibt es analog zum Pretty Printer keine Funktion, die zu jedem Attribut eine SET- und eine GET-Methode erzeugt? Warum muss ich sowas selbst schreiben (also eben diesen Generator)?
https://help.sap.com/doc/saphelp_nw75/7 ... cache=true
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Führende Nullen löschen

Beitrag von black_adept (Top Expert / 3366 / 65 / 632 ) » 01.07.2020 09:19
Nachtrag zu vorherigem Posting von mir.
Einerseits wird sich Ralf über den Link freuen. Andererseits freue ich mich schon darauf dass er jetzt seine Signatur ändern muss wenn er sich den vom Stub erzeugten Code anschaut 😜
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Führende Nullen löschen

Beitrag von ralf.wenzel (Top Expert / 3527 / 161 / 242 ) » 01.07.2020 10:31
Wegen i_ und r_? Ach, SO streng sehe ich das gar nicht. Es gibt Kollegen, die zu beobachten meinen, eine gewisse Altersmilde habe mich erfasst.


Ralf

Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
Romaniac


Re: Führende Nullen löschen

Beitrag von msfox (Specialist / 110 / 16 / 15 ) » 01.07.2020 11:05
DeathAndPain hat geschrieben:
30.06.2020 19:43
Ihr habt recht; ich war hier schon etwas sarkastisch. Wobei ich speziell in diesem Fall durchaus der Meinung bin, dass der SHIFT-Befehl nicht nur die schnellste, sondern zugleich auch für den Leser verständlichste Variante ist. Ich jedenfalls würde den SHIFT sofort verstehen, bei

Code: Alles auswählen.

i_field = |{ i_field ALPHA = OUT }|.
aber erst mal grübeln und nachlesen müssen, was diese Syntax mir genau sagen möchte. Und wenn ich sie verstanden hätte, müsste ich mir auch noch ins Gedächtnis rufen, was der Alpha-Konvertierungsexit genau tut.
Nein, es kommt darauf an, was du machen willst. Wenn du wirklich die führenden Nullen löschen willst, dann via SHIFT. Wenn du aber für die Ausgabe auf dem Bildschirm die Daten von der DB für den User anpassen willst z.B. führenden Nullen entfernen, dann via ALPA-Konvertierung. Die ALPHA-Konvertierung ist dabei eine Blackbox. Insbesondere bei PSP-Nummer sollte man nicht einfach führende Nullen löschen, nur weils dann schöner aussieht.

Re: Führende Nullen löschen

Beitrag von DeathAndPain (Top Expert / 1386 / 148 / 324 ) » 06.07.2020 19:49
Ralf hat geschrieben:Danke für die Blumen. Aber ich möchte dir in einigen Punkten widersprechen: Gerade hier laufen einige Leute herum, die eine enorme Klasse haben. Und jeder ist auf seinem Gebiet irgendwo herausragend. Ich nenne jetzt extra keine Namen, aber die Regulars, die ich meine, fühlen sich sicher angesprochen.
Deswegen meinte ich "fast". Hier im Forum hast Du eine sehr hohe Dichte solcher Leute, denn die, die hier seit Jahren rumlaufen, zeigen doch schon dadurch, dass sie der Theorie guten Codes ein hohes Interesse entgegenbringen. Lass es insgesamt gefühlt 10 Leute sein, die hier 95% der hochwertigen Antworten schreiben. Geografisch verteilen die sich über ganz Deutschland. Die Entwickler, die Du in Masse draußen in freier Wildbahn antriffst, sind ein deutlich kleineres Kaliber. Das scheint ja bis in die Akademien reinzureichen. Du brauchst Dir nur anzuschauen, was die ABAP-Neueinsteiger, die hier Fragen stellen, für Beispielcode bieten, dann erkennst Du schon, dass selbst diejenigen, die sie unterrichten, offenkundig veraltetes ABAP vermitteln. Und zwar in praktisch allen Fällen, die mir hier untergekommen sind, nicht nur in Fällen, bei denen sich jemand selber was angelesen hat. Gerade bei der Neuausbildung von ABAP-Entwicklern sollte man doch annehmen, dass nur noch 7.40-Syntax unterrichtet wird (das andere kann man hinterherschieben, damit die Leute älteren Code auch lesen können, aber was man zuerst lernt, gewöhnt man sich an, daher wäre die Reihenfolge wichtig). Aber kannste offenbar vergessen.

So eingebildet es klingen mag: Wir hier sind die Elite. Es wird in Deutschland sicherlich noch ein paar mehr geben, die auf vergleichbarem Niveau sind. Aber prozentual gesehen verschwindend wenige.
Ralf hat geschrieben:Ein Singleton hat durchaus seine Berechtigung, sonst gäbe es kein Singleton-Pattern. Eine statische Methode kann ich in der Ableitung zum Beispiel nicht redefinieren, was einen großen Teil meiner Entwicklungen deutlich erschweren würde.
Wenn ich eine derartige Anwendung bei fremdem Code sehen würde, würde ich sofort den Mund halten. Aber wie ich schon sagte: Du machst sowas. Die Masse nicht. Aber auch die Masse arbeitet trotzdem mit Instanzmethoden, die dadurch reiner Wasserkopf sind.
Ralf hat geschrieben:Dass Attribute etwas anderes sind als Variablen, doziere ich seit Jahr und Tag. Ich frage mich nur: Warum gibt es analog zum Pretty Printer keine Funktion, die zu jedem Attribut eine SET- und eine GET-Methode erzeugt? Warum muss ich sowas selbst schreiben (also eben diesen Generator)? Dann würde die Faulheit "ach, mach ich's halt public" nicht ständig siegen.
Nach meiner Überzeugung reicht das nicht. Private Methoden sieht man schon öfter mal, aber auch dort sind die Attribute von ihrer Anwendung her nichts anderes als klassenglobale Variablen. Wer an der Klasse was machen muss, der muss an diesen Code ran, und dem nützt es gar nichts, dass das private ist, denn innerhalb der Klasse sind auch private-Attribute überall frei zugänglich, und Klassen können sehr groß sein.

Wie gesagt, nach meiner Überzeugung darf man mit einem Attribut gar nicht hantieren können wie mit einem normalen Feld. Und wenn es die von mir vorgeschlagenen GET ATTRIBUTE und SET ATTRIBUTE-Befehle geben würde, dann bräuchtest Du auch keine editorseitige Hilfsschablone, die Dir einen codeverlängenden Wasserkopf für die GETTER und SETTER-Methoden erzeugt, sondern dann hättest Du das implizit in ABAP drin. Und dann könnte man auch innerhalb der Klasse das Attribut nicht einfach wie ein Feld verwenden.
In aller Regel ist es reine Faulheit, soweit ich das beobachten konnte.
Ich schlage mich hier mit Code eines Exkollegen herum, der war Idealist. Nur offenbar hat er die entsprechenden Schnittstellenkonzepte nicht wirklich verstanden. Was der auf der einen Seite an Wasserkopfkapselungen gebaut hat, die mit Sicherheit eine Menge Arbeit gemacht haben, auf der anderen Seite aber an parameter- und kommentarlosen Methoden verwendet, die er liebevoll in separaten Googledocs außerhalb des SAP-Systems dokumentiert und die sich aus in Attributen abgelegten Werten speisen, das geht auf keine Kuhhaut. (In diesen Googledocs stehen die Konzepte drin und was die Klassen usw. machen bzw. machen sollen. Den unkommentierten Code, der das umsetzen soll, versteht man dadurch natürlich trotzdem nicht, denn die Idee ist eine Sache, die Umsetzung eine andere. Deswegen bin ich ein starker Verfechter davon, direkt im Code reichlich Kommentar einzubauen, der Schritt für Schritt erklärt, was ich da mache, mit welchen Gedanken und welchem Ziel. Das tue ich schon mir selbst zuliebe, damit ich nach einem Vierteljahr meinen eigenen Code noch verstehe. Dafür bin ich mit der externen Dokumentation deutlich träger.)

Einmal war die explizite Stakeholder-Anforderung, Werte so zu ermitteln, wie jener Kollege es in seiner Klasse macht. Mit einem anderen Entwickler zusammen habe ich versucht, die Klasse auseinanderzunehmen und zu analysieren, wo die Werte herkommen. Alles, was mir am Ende gelungen ist, ist einen Weg zu finden, die Routinen aufzurufen, mit denen er es innerhalb der Klasse macht. Wie diese funktionieren und wo die Werte herkommen, haben wir (mit auch nur halbwegs vertretbarem Aufwand) nicht ergründen können, da alle Aufrufe parameterfrei waren und alle Werte aus Attributen entnommen und darin wieder verstaut wurden.

Diese Routine, die ich da aufrufe, macht letztlich nicht mehr, als die Werte für eine einzige Spalte meines Reports zu liefern, der viele Spalten unterschiedlichster Herkunft zu einem Mitarbeiter ausgibt. Von der Rechenzeit her entfallen bei meinem Report jetzt 95% auf diese eine Spalte. Und das liegt nicht daran, dass der Inhalt so ein Hexenwerk wäre. Wenn die Stakeholder es hinbekommen würden, die Anforderung an diese Spalte sauber zu definieren, anstatt nur zu sagen, wir wollen das so, wie es auch in jenem anderen Code (des Kollegen) rauskommt, dann bin ich überzeugt, dass es mir ein leichtes wäre, das in einem Bruchteil der Zeit mit um Größenordnungen höherer Performance neu zu programmieren. Den Stakeholdern kann man an der Stelle sicherlich auch einen Vorwurf machen, dass sie offenbar gar nicht genau wissen, was sie eigentlich wollen. Das ändert aber nichts an der von mir geschilderten Codeproblematik.
a-dead-trousers hat geschrieben:Es ist leider nicht immer nur die Faulheit.
Viele ABAP-Befehle verstehen bis heute noch nicht mit einem Methodenaufruf umzugehen. Ein konkretes Beispiel ist die zwingende Verwendung von Variablen im SELECT-Befehl. "WHERE x = lr_object->get_filter_x( )" geht da nicht.
Während ich Dir durchaus zustimme, dass mehr Flexibilität bei SELECTs durchaus wünschenswert wäre, bin ich nicht sicher, ob das ein gutes Beispiel ist. Ein Attribut per funktionaler Methode direkt im SELECT zu beschaffen, hmmm... ich persönlich denke, dass einem kein Zacken aus der Krone bricht, wenn man für die Attribute, die man in einem Codeabschnitt braucht, dort ein lokales Feld deklariert und sie dorthinein importiert.

Ein

Code: Alles auswählen.

DATA(attrib_x) = lr_object->get_filter_x( ).
SELECT bla WHERE x = attrib_x
liest sich in meinen Augen ganz wunderbar, IMHO tatsächlich sogar besser verständlich als Deine Version, auch wenn die kürzer ist. Da spielt auch eine zweite Schwäche von Attributen in ihrer derzeitigen Implementierung hinein, nämlich dass man optisch nicht gut unterscheiden kann, ob etwas ein Attribut oder eine funktionale Methode ist. Ich weiß, die Methode erkennt man an den Klammern, aber im Gewusel komplexen Codes, wo man bei komplizierteren Ausdrücken auch sonst eine Menge Klammern drin hat, geht sowas optisch leicht unter, und ich bin da durchaus schon das eine oder andere Mal auf's Glatteis geführt worden, bis der Debugger mir gezeigt hat, was da abgeht. Bei meinem obenstehenden Beispiel ist attrib_x sehr schön als Attribut mit Datenherkunft und -verwendung zu erkennen.

Re: Führende Nullen löschen

Beitrag von ralf.wenzel (Top Expert / 3527 / 161 / 242 ) » 06.07.2020 23:44
Nur eines noch zum Singleton (ist schon spät, mein Tag beginnt um 5, sowohl der heutige als auch der morgige): Ich mache das inzwischen grundsätzlich so, ich hab in meinem Leben zu viele Klassen umgebaut von statisch auf Instanz (weil dann doch eine Ableitung gebraucht wurde z. B.) als dass ich das nochmal machen wollte.

Mit statischen Klassen arbeite ich praktisch gar nicht mehr. Die sind mir zu unflexibel.


Ralf *pendelt 4x/Woche von HH nach B....

Re: Führende Nullen löschen

Beitrag von msfox (Specialist / 110 / 16 / 15 ) » 07.07.2020 08:45
ralf.wenzel hat geschrieben:
06.07.2020 23:44
Mit statischen Klassen arbeite ich praktisch gar nicht mehr. Die sind mir zu unflexibel.
Dem kann ich nur zustimmen.
1) statische Methoden: Mache ich i.d.R.* nicht. Ein Kollege wollte dies unbedingt, weil er sich zu "schade" war, von der Klasse eine Instanz bilden.
*außer bei Util-Klassen.

2) Beim Singleton bin ich mal auf die Nase gefallen. Wir haben eine WDY-Anwendung auf viele WDY-Komponenten verteilt. Damit jede Komponente die gleiche Insanze nutzt, war die Klasse SingleTon. Blöd nur, dass es dann ein WDY-Komponente gab, die ihre eigene Instanz braucht... Also wieder umgebaut.


Aktuelle Forenbeiträge

Upload Dateitypen - Content ermitteln
vor 8 Stunden von STDIN 1 / 15
Best Practice IDOC Typen
Gestern von Basler84 1 / 127

Vergleichbare Themen

Führende Nullen
von Beginner014 » 24.10.2014 08:51
führende Nullen
von tabea* » 14.04.2007 09:21
Führende Nullen
von Kelly » 05.10.2005 09:48
führende Nullen in char fel
von F12_man » 25.05.2007 12:12
Führende Nullen anzeigen
von Michael_1 » 14.10.2004 10:47