Moderne Entwicklungsprozesse bei SAPlern
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Dann zitiere ich mal weiterblack_adept hat geschrieben: Warum eigentlich immer dieses Entweder/Oder? Nenne deine Tabellen LT_UMBEST oder von mir aus sogar LT_EKKO_UMBEST und du machst beide Lager glücklich.
Oder in kurzen Worten: Warum soll man die Welt mit Formalismen über redundante Informationen verkomplizieren? Warum soll man etwas tun, was offensichtlich keinen Sinn macht? Und tippen muss man den ganzen Kram dann ja auch noch....gibt es so viele technische Eigenschaften eines Objektes, dass diese nicht durch einfache Regeln (...) abbildbar sind. (...)Bezüglich des Datentyps eines Datenobjektes gibt es beispielsweise Namenskonventionen, in denen die Buchstaben v und c als Präfixe für variable oder konstante elementare Datenobjekte stehen und s und t als Präfixe für Strukturen und interne Tabellen. (...) Wenn dann noch gleichzeitig die Eigenschaften "statische Variable" und "sortierte Tabelle" ebenfalls über s ausgedrückt werden sollen, wird das mit hoher Wahrscheinlichkeit zu Fehlern (Anm. von mir: und Konflikten!) in der Namensvergabe führen, und dem Ziel lesbarer und selbstdokumentierender Quelltexte wird man so nur schwerlich näherkommen.
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
solche Präfixe in Namenskonventionen sind wohl redundant, aber nicht völlig sinnlos.
Nicht selten komme ich in Verlegenheit, fremdes Coding auf einen bestimmten Fehler hin zu untersuchen. Dabei kann mir ein Präfix behilflich sein.
Beispiel:
CLEAR bestellungen.
Was macht das hier? Ist bestellungen nur eine Variable, ein Arbeitsbereich oder gar eine interne Tabelle? Mit Präfix sehe ich das gleich und manchmal erkennt man daran auch gleich den Fehler. Z.B. sollte an dieser Stelle nur ein Arbeitsbereich geleert werden und nicht gleich die komplette interne Tabelle.
Statt "CLEAR lt_bestellungen" sollte also "CLEAR ls_bestellungen" stehen.
Klar sagt mir ein Doppelklick auf bestellungen auch gleich, was hier geleert wird, aber das unterbricht wieder meinen Lesefluss, was ich persönlich als deutlich nerviger erachte als mich an bestimmte vereinbarte Namenskonventionen zu halten.
Nur ein kleines Bespiel von vielen, die mir schon begegnet sind.
Will sagen: Pauschale Urteile wie "Namenskonventionen sind überflüssig oder auch unabdingbar" (je nach Standpunkt), halte ich für wenig zielführend. Aber wie bei fast allem ist "Maß halten" das Zauberwort. Man sollte sich hüten, in Präfixen alle möglichen Infos über eine Variable unterzubringen. Max 2 Zeichen reichen dazu aus.
Nicht selten komme ich in Verlegenheit, fremdes Coding auf einen bestimmten Fehler hin zu untersuchen. Dabei kann mir ein Präfix behilflich sein.
Beispiel:
CLEAR bestellungen.
Was macht das hier? Ist bestellungen nur eine Variable, ein Arbeitsbereich oder gar eine interne Tabelle? Mit Präfix sehe ich das gleich und manchmal erkennt man daran auch gleich den Fehler. Z.B. sollte an dieser Stelle nur ein Arbeitsbereich geleert werden und nicht gleich die komplette interne Tabelle.
Statt "CLEAR lt_bestellungen" sollte also "CLEAR ls_bestellungen" stehen.
Klar sagt mir ein Doppelklick auf bestellungen auch gleich, was hier geleert wird, aber das unterbricht wieder meinen Lesefluss, was ich persönlich als deutlich nerviger erachte als mich an bestimmte vereinbarte Namenskonventionen zu halten.
Nur ein kleines Bespiel von vielen, die mir schon begegnet sind.
Will sagen: Pauschale Urteile wie "Namenskonventionen sind überflüssig oder auch unabdingbar" (je nach Standpunkt), halte ich für wenig zielführend. Aber wie bei fast allem ist "Maß halten" das Zauberwort. Man sollte sich hüten, in Präfixen alle möglichen Infos über eine Variable unterzubringen. Max 2 Zeichen reichen dazu aus.
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
ok, nehmen wir an, die Tabelle heißt nicht "Bestellungen", sondern LT_EKKO - und weil wir mehrere Arten von Bestellungen selektieren, heißen die LT_EKKO1, LT_EKKO2 etc. (hab ich wirklich schon in Codings gesehen!).
Dann weiß ich zwar: Hey, das ist ne Tabelle, die gelöscht wird. Aber ob es die mit den Umlagerungsbestellungen oder die mit den Angeboten oder die mit den CC-Bestellungen ist, weiß ich dann immer noch nicht. Und diese Info ist weit tiefer versteckt als die Deklaration.
BTW: Arbeitsbereiche, das sind doch die Dinger, die man benutzt hat, ehe es Feldsymbole gab, ne?
Dann weiß ich zwar: Hey, das ist ne Tabelle, die gelöscht wird. Aber ob es die mit den Umlagerungsbestellungen oder die mit den Angeboten oder die mit den CC-Bestellungen ist, weiß ich dann immer noch nicht. Und diese Info ist weit tiefer versteckt als die Deklaration.
BTW: Arbeitsbereiche, das sind doch die Dinger, die man benutzt hat, ehe es Feldsymbole gab, ne?
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
das ist dann ja wieder eine andere Baustelle, die nicht direkt mit den Präfixen zu tun haben.
Der nächste Punkte wäre: Aussagekräftige Variablennamen. Das ist zugegebenermaßen wieder eine Kunst für sich. Alteingesessene ABAP'ler verwenden gerne direkt die Tabellennamen, weil sie wissen, was sich dahinter verbirgt. Ich habe es mir angewöhnt, diese nur dann zu verwenden, z.B. lt_ekko, wenn dahinter auch tatsächlich nur die Struktur dieser Tabelle liegt. Ansonsten verwende ich sprechendere Namen, die keinen direkten Bezug zu einer Tabelle haben, weil das meiner Meinung nach nur mehr verwirrt.
Statt Arbeitsbereiche hätte ich wohl besser Strukturen gesagt à la "data: ls_ekko type ekko.". Als ich im frühen 14. Jahrhundert erstmals in einer Umschulung mit ABAP in Kontakt kam, verwendete man noch Tabellen mit Kopfzeile, was man als Tabellenarbeitsbereich bezeichnete.
Der nächste Punkte wäre: Aussagekräftige Variablennamen. Das ist zugegebenermaßen wieder eine Kunst für sich. Alteingesessene ABAP'ler verwenden gerne direkt die Tabellennamen, weil sie wissen, was sich dahinter verbirgt. Ich habe es mir angewöhnt, diese nur dann zu verwenden, z.B. lt_ekko, wenn dahinter auch tatsächlich nur die Struktur dieser Tabelle liegt. Ansonsten verwende ich sprechendere Namen, die keinen direkten Bezug zu einer Tabelle haben, weil das meiner Meinung nach nur mehr verwirrt.
Statt Arbeitsbereiche hätte ich wohl besser Strukturen gesagt à la "data: ls_ekko type ekko.". Als ich im frühen 14. Jahrhundert erstmals in einer Umschulung mit ABAP in Kontakt kam, verwendete man noch Tabellen mit Kopfzeile, was man als Tabellenarbeitsbereich bezeichnete.
Hi,zzcpak hat geschrieben:solche Präfixe in Namenskonventionen sind wohl redundant, aber nicht völlig sinnlos.
Nicht selten komme ich in Verlegenheit, fremdes Coding auf einen bestimmten Fehler hin zu untersuchen. Dabei kann mir ein Präfix behilflich sein.
Beispiel:
CLEAR bestellungen.
Was macht das hier? Ist bestellungen nur eine Variable, ein Arbeitsbereich oder gar eine interne Tabelle? Mit Präfix sehe ich das gleich und manchmal erkennt man daran auch gleich den Fehler. Z.B. sollte an dieser Stelle nur ein Arbeitsbereich geleert werden und nicht gleich die komplette interne Tabelle.
Statt "CLEAR lt_bestellungen" sollte also "CLEAR ls_bestellungen" stehen.
Klar sagt mir ein Doppelklick auf bestellungen auch gleich, was hier geleert wird, aber das unterbricht wieder meinen Lesefluss, was ich persönlich als deutlich nerviger erachte als mich an bestimmte vereinbarte Namenskonventionen zu halten.
Nur ein kleines Bespiel von vielen, die mir schon begegnet sind.
Will sagen: Pauschale Urteile wie "Namenskonventionen sind überflüssig oder auch unabdingbar" (je nach Standpunkt), halte ich für wenig zielführend. Aber wie bei fast allem ist "Maß halten" das Zauberwort. Man sollte sich hüten, in Präfixen alle möglichen Infos über eine Variable unterzubringen. Max 2 Zeichen reichen dazu aus.
das ist eigentlich ein schönes Beispiel. "clear bestellungen" ist sicherlich missverständlich. Die Programmierrichlinien sagen aber auch hier, für "lt_bestellungen" sollte eigentlich "bestellungen" und für "ls_bestellungen" eigentlich "bestellung" genügen. Ich persönlich versuche das auch immer so einzuhalten. Ich gebe zu, es geht nicht immer so ohne weiteres.
sieher hierzu:
http://help.sap.com/abapdocu_731/de/index.htm
ABAP-Schlüsselwortdokumentation → ABAP - Programmierrichtlinien → Aufbau und Stil → Namensgebung → Programminterne Namen
Das mit den Präfixen habe ich früher auch so gehandhabt, bin aber mittlerweile so gut wie weg von. In dem Präfix kann man halt z.B. nicht vernünftig verschlüsseln um welche Art von Tabelle es sich handelt oder welcher Zugriffskey sich dahinter verbirgt. Letztendlich muss man doch den Doppelclick machen.
Eigentlich sollte das jeder so machen, wie er am besten damit zurecht kommt (macht wahrscheinlich sowieso jeder). Die Präfixe habe mir früher schon viel geholfen, wenn man sich in einem globalen Reportumfeld gearbeitet hat. Heute sind sie für mich nicht mehr so relevant.
Viele Grüße,
...entwickelnder Berater...beratender Entwickler
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Da steht - Überraschung, Überraschung - genau dasselbe drin wie im Buch ABAP-Programmierrichtlinien von SAP Presserp-bt hat geschrieben:das ist eigentlich ein schönes Beispiel. "clear bestellungen" ist sicherlich missverständlich. Die Programmierrichlinien sagen aber auch hier, für "lt_bestellungen" sollte eigentlich "bestellungen" und für "ls_bestellungen" eigentlich "bestellung" genügen. Ich persönlich versuche das auch immer so einzuhalten. Ich gebe zu, es geht nicht immer so ohne weiteres.
sieher hierzu:
http://help.sap.com/abapdocu_731/de/index.htm
ABAP-Schlüsselwortdokumentation → ABAP - Programmierrichtlinien → Aufbau und Stil → Namensgebung → Programminterne Namen
Und genau der Fall ist dort auch beschrieben: Tabelle = Mehrzahl, Arbeitsbereich/Feldsymbol/Feld = Einzahl. Denn "ls_bestellungen" ist eh widersprüchlich, weil da ja nur eine drinstehen kann Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
es geht ja auch ls_bestellung und lt_bestellungen *gg*
Und was die Programmierrichtlinien der SAP angeht ... ich sehe nicht viel SAP-Code, der sich konsequent daran hält.
Bei uns sind die Präfixe Pflicht und werden durch den Code Inspector sehr penibel geprüft.
Ich sehe das auch eher als Nebensächlichkeit an, über die man sich mal kurz aufregen kann, aber andere Themen sind in meinen Augen wichtiger, z.B.
Und was die Programmierrichtlinien der SAP angeht ... ich sehe nicht viel SAP-Code, der sich konsequent daran hält.
Bei uns sind die Präfixe Pflicht und werden durch den Code Inspector sehr penibel geprüft.
Ich sehe das auch eher als Nebensächlichkeit an, über die man sich mal kurz aufregen kann, aber andere Themen sind in meinen Augen wichtiger, z.B.
- Sinnvolle Benennung von Variablen
Übersichtliche und gut strukturierte Programme
keine Eierlegende-Wollmilchsau-Klassen (Gott-Klassen)
etc ...
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Richtig, darum sollte man sich nicht damit aufhalten, feingliedrige Formalismen aufzustellen für total unwichtige Dingezzcpak hat geschrieben:andere Themen sind in meinen Augen wichtiger
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Spassbremse LOLzzcpak hat geschrieben:umgekehrt sollte man sich aber auch nicht damit aufhalten, dagegen zu wettern, wenn sich diese Vorgehensweise bei einem Kunden findet, der schon Jahre nach diesen Richtlinien arbeitet.
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Unbeantwortete Forenbeiträge
Custom logic - Feld wieder initialisieren (BADI CRMS4_SERV_CUST_H_MODIFY)
vor 3 Wochen von JanR 1 / 96225
vor 3 Wochen von JanR 1 / 96225
F6862 - Stücklistenpositionen Massenhinzufügen ohne Änderungsnummer
April 2026 von Radinator 1 / 158806
April 2026 von Radinator 1 / 158806