Hallo zusammen,

es geht darum, dass sowas mit Namenskonventionen, Bennenungen, etc. regelmäßig vom TL in Firmenrichtlinien angepasst wird und man wenn man an Code was macht auch den alten Code anpassen soll.

Vor allem es sind auch Anpassungen dabei, die nicht Standard in anderen Firmen sind.

Es geht um ABAP.
z.b. es wird beschlossen dass in Klassen Attribute nicht mehr mit m*_* anfangen, sondern mit a*_* (z.b. av_vkorg statt mv_vkorg) und dann soll ganzer Code angepasst werden.
Genau so wie z.b. Selektionsparameter statt se_* s_*, usw.

Dann soll sprechende Namen verwendet werden.
z.b gab es früher DATA gv_vbeln TYPE vbpa-vbeln soll jetzt auf DATA gv_sales_document_number TYPE vbpa-vbeln unbenannt werden
Und das bei alten Code, wo man evtl ein paar Zeilen ändert und dafür zum Teil hundert Variablen anpassen muss.
Dazu ist für mich schneller den Code zu verstehen, wenn die Namen gleich benannt sind, wie die Datenbankfeldnamen.
Ich finde das ist unnötige Arbeit welche Zeit verschwendet und zum Teil kontraproduktiv ist.

Was denkt ihr darüber?

vor 5 Stunden, hund555 hat gesagt:

Arbeit welche Zeit verschwendet und zum Teil kontraproduktiv ist.

Kommt halt darauf an warum diese Änderungen erzwungen werden.

Sollte es sein, um verschiedene Codebasen einheitlich zu bekommen finde ich das ganze durchaus sinnvoll oder wenn man einen allgemeinen Standard einhalten möchte.

Wird es aber hingegen erzwungen weil irgendeiner aus der Führung zu viel Freizeit hat ist es halt eine ABM (Arbeitsbeschaffungsmaßnahme). Im Endeffekt hat es dich aber auch nicht zu interessieren. Du bekommst dein Geld für Leistung und wenn der AG möchte, dass du deine wertvolle Arbeitskraft verwendest um Variablen umzubenennen sei es drumm. Es ist ja nicht dein Geld und sollte die Arbeit dadurch langfristig eintönig werden kann man entweder das Gespräch suchen und falls das nicht wirkt eben den AG wechseln.

Vllt. habe ich als beamter aber auch ein zu dickes Fell was unsinniger, bürokratischer Mist angeht. Würde ich mich über jede ABM, Verordnungspunkt usw. aufregen den ich als unnötig empfinde, hätte ich schon mindestens 3x Herzinfarkte erlitten.

Bearbeitet Freitag um 13:594 Tage von skylake

vor 57 Minuten, skylake hat gesagt:

Es ist ja nicht dein Geld und sollte die Arbeit dadurch langfristig eintönig werden kann man entweder das Gespräch suchen und falls das nicht wirkt eben den AG wechseln.

Stimme ich auch zu.

Wenn du v. Management die Anweisung kriegst, eine ABM durchzuführen, dann kannst du vl. darauf hinweisen, dass es nicht gut ist, aber am Ende machst du es. Dagegen hart anzukämpfen sorgt nur dafür, dass du mehr graue Haare kriegst und d. Mgmt sitzt am längeren Hebel.

Am 24.10.2025 um 10:12, hund555 hat gesagt:

av_vkorg

mv_vkorg

DATA gv_vbeln TYPE vbpa-vbeln

Mit solchen Variablennamen hätte ich schon längst gekündigt

Am 25.10.2025 um 12:32, Shun hat gesagt:

Mit solchen Variablennamen hätte ich schon längst gekündigt

Dann kommst du nicht aus SAP Welt.
Vbeln sagt jedem SAPler sofort was, wenn ich statt dessen Sales_document_number nehme, muss der Code analysiert werden welcher Wert aus SAP Tabelle sich dort befindet.
Ähnlich vkorg, kennt jeder SAPler.

Die SAP-Ordnung (Büro-Satire)
„Freiheit ist Compliance.“

1. „Alles ist optional – solange du es genau so machst.“

2. „Abweichungen sind willkommen (nach dreifacher Genehmigung in 12 Stufen).“

3. „Eigeninitiative = Ticket eröffnen.“
   
   §1: Du sollst keine anderen Systeme neben mir haben.
   §2: Felder sind leer, bis sie vorschriftsmäßig gefüllt sind.
   §3: Benutzerrechte werden nur bei Bedarf erteilt – Bedarf wird zentral festgestellt.
   §4: Customizing ist frei. Frei nach Vorgabe.
   §5: Wer fragt, bekommt ein Workflow.
   §6: Der Prozess hat immer recht.

Am 24.10.2025 um 10:12, hund555 hat gesagt:

es geht darum, dass sowas mit Namenskonventionen, Bennenungen, etc. regelmäßig vom TL in Firmenrichtlinien angepasst wird und man wenn man an Code was macht auch den alten Code anpassen soll.

Und dann wundert man sich, wenn Projekte scheitern? Hatte auch mal so einen Chef. Einfach furchtbar.

Meine Meinung: Code muss für den Kunden geil sein. Am Ende muss es laufen, sicher sein und im Idealfall rechtlich einwandfrei. Die Namenskonvention und "schöner" Code kommen danach. Sonst machst du in der SE keine Umsätze.

EDIT: Alles im Bereich von Algorithmen, Komplexitätstheorie, Architektur und Design, muss den Bedürfnissen des Kunden eingeordnet werden. Eine Optimierung von O(n^2) zu O(logn) ist es nicht wert, wenn der Kunde das nicht spürt und es dir somit keinen Marktvorteil verschafft.

Wenn du ein Framework aufbaust, das von SAPlern genutzt wird, dann kann eine Namensänderung durchaus sinnvoll sein. Aber nicht andauernd. Da kann ich mein Geld auch gleich in die Weser werfen.

Bearbeitet Gestern um 08:311 Tag von chhu

Am 24.10.2025 um 10:12, hund555 hat gesagt:

av_vkorg statt mv_vkorg

Das finde ich noch relativ sinnvoll, wenn man sowie schon etwas anpasst. Also eine gewisse Einheitlichkeit schaffen.

Am 24.10.2025 um 10:12, hund555 hat gesagt:

DATA gv_vbeln TYPE vbpa-vbeln soll jetzt auf DATA gv_sales_document_number TYPE vbpa-vbeln

Das steht für mich im Gegensatz zum Obigen. Ich würde mich immer auf das Tabellenfeld/Datenelement beziehen, denn es ist wesentlich einfacher nachzuvollziehen/analysieren.

vor 3 Stunden, hund555 hat gesagt:

Dann kommst du nicht aus SAP Welt.
Vbeln sagt jedem SAPler sofort was, wenn ich statt dessen Sales_document_number nehme, muss der Code analysiert werden welcher Wert aus SAP Tabelle sich dort befindet.
Ähnlich vkorg, kennt jeder SAPler.

Absolut korrekt, ich bin noch nie im SAP Umfeld gewesen. Und vielen Dank für die Warnung, ich werde niemals dorthin gehen, das klingt ja wild 😂

vor 2 Stunden, Shun hat gesagt:

das klingt ja wild

Das Beispiel oben ist noch human.

Haben viele altbackene Programme in denen die damaligen Kollegen Variablen hochgezählt haben.

Dann kommt auf einmal Summe1 - Summe14 und ähnliches.😂