Führende Nullen löschen

Re: Führende Nullen löschen

Re: Führende Nullen löschen

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

Re: Führende Nullen löschen

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

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.