Quality Management - Programmierrichtlinien
14 Beiträge
•
Seite 1 von 1
14 Beiträge
Seite 1 von 1
Hallo,
ich habe vor 2 Wochen die Anforderung bekommen, dass ich bei uns den SCI ( Code Inspector ) in Verbindung mit ATC ( ABAP Test Cockpit ) einrichten und anschließend auch betreuen soll.
Bisher habe ich reine ABAP Programmierung gemacht und bin der Meinung, dass ich dort auch recht fit bin!
Jetzt war meine Frage, ob es etwas in die Richtung "Quality Manager" gibt?
Es soll nämlich auch so sein, dass unser Solution Manager System die Prüfungen macht und dann gegebenenfalls weiter transportiert oder eben den Transport blockt. Und da dass dann für all unsere Systeme ( BW, FI/CO/PP, HCM ) gilt war ich am überlegen, ob es sich einerseits lohnt dort eine Art neue Stelle für sowas einzurichten ( bzw. es meinem Vorgesetzten vorschlagen, dass der das dann macht ^^ )
Meint ihr es lohnt sich auch Zeitmäßig so eine Art "QM" aufzubauen oder ist das eher sinnlos?
Danke euch.
Gruß
ich habe vor 2 Wochen die Anforderung bekommen, dass ich bei uns den SCI ( Code Inspector ) in Verbindung mit ATC ( ABAP Test Cockpit ) einrichten und anschließend auch betreuen soll.
Bisher habe ich reine ABAP Programmierung gemacht und bin der Meinung, dass ich dort auch recht fit bin!
Jetzt war meine Frage, ob es etwas in die Richtung "Quality Manager" gibt?
Es soll nämlich auch so sein, dass unser Solution Manager System die Prüfungen macht und dann gegebenenfalls weiter transportiert oder eben den Transport blockt. Und da dass dann für all unsere Systeme ( BW, FI/CO/PP, HCM ) gilt war ich am überlegen, ob es sich einerseits lohnt dort eine Art neue Stelle für sowas einzurichten ( bzw. es meinem Vorgesetzten vorschlagen, dass der das dann macht ^^ )
Meint ihr es lohnt sich auch Zeitmäßig so eine Art "QM" aufzubauen oder ist das eher sinnlos?
Danke euch.
Gruß
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ich bin ein Hardliner in diesem Thema. Ein QM ist absolut unverzichtbar, wobei im SCI in meinen Augen die Ungarische Notation einen enormen Stellenwert hat. Was ich davon halte, ist bekannt. Man kann QM auch nicht immer automatisieren, denn sowas wie "sprechende und einheitliche (!) Objekt-, Methoden- und Variablennamen" kann eine Automatik nicht erfassen. Es braucht also einen Codingverantwortlichen, der für die Codingqualität verantwortlich zeichnet. Der nimmt jedes Coding ab und sollte z. B. erkennen "das haben wir schon wo" oder "das brauchen wir noch öfters" und das Coding zurückweisen mit der Anweisung "Serviceklasse schreiben". Keine Doku? Geht nicht produktiv. Unter gar keinen Umständen!
Wie sagte ich bei einem langjährigen Kunden immer wieder? "Wenn ihr eure XXX* so bauen würdet wie eure IT ihr Produkt baut, wäre der Laden hier längst pleite!" (*Produktname aus Anonymisierungsgründen entfernt). Ich kann keinen Grund erkennen, warum ein SAP-Coding niedrigeren Qualitätsansprüchen genügen sollte als z. B. ein Schaltschrank. Da gibt es auch feste Regeln und Pläne und der Elektroniker (das habe ich zufällig mal gelernt!) sagt auch nicht "im Plan steht rotes Kabel, das ist aus und müsste ich aus dem Lager holen -- nehme ich halt blaues, geht viel schneller". Das wäre indiskutabel!!!
Ralf
Wie sagte ich bei einem langjährigen Kunden immer wieder? "Wenn ihr eure XXX* so bauen würdet wie eure IT ihr Produkt baut, wäre der Laden hier längst pleite!" (*Produktname aus Anonymisierungsgründen entfernt). Ich kann keinen Grund erkennen, warum ein SAP-Coding niedrigeren Qualitätsansprüchen genügen sollte als z. B. ein Schaltschrank. Da gibt es auch feste Regeln und Pläne und der Elektroniker (das habe ich zufällig mal gelernt!) sagt auch nicht "im Plan steht rotes Kabel, das ist aus und müsste ich aus dem Lager holen -- nehme ich halt blaues, geht viel schneller". Das wäre indiskutabel!!!
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Ich finde die Einstellung gut!
Leider müssen wir die nächsten 10 Jahre die Ungarische Notation noch durchlassen, bin selber auch kein Fan davon.
Ich habe im SCI es tatsächlich soweit hinbekommen, dass bei der UN eine Warnung erscheint, blockieren kommt später.
Aber du hast recht, man kann nicht alles automatisieren, man kann es aber soweit es geht versuchen! z. B. Dokumentation. Wir haben eine Schnittstelle, die uns einerseits die Doku im SAP System direkt liefert und die Dokumentation die wir im Sol-Man anhängen. Erst wenn beides vorhanden ist ( und die SAP Doku gewisse Bereiche abdeckt ) wird der Transport durchgelassen. ( zumindest ist das der Plan ) Oder halt andere Themen, die man leichter automatisieren kann ( Übersetzungen - prüfen ob eine vorhanden ist --> alle Übersetzungen zu manuell zu prüfen würde gar nicht gehen ... sonst müsste ich 3 Sprachen zusätzlich zu deutsch und englisch sprechen ( im HCM Bereich reicht es bei uns, wenn ich den namen des programms nehme und daraus dann das land und die jeweilige übersetzung lese ) - oder kommentare prüfen ob sie englisch sind oder eben nicht ( vorgabe ist natürlich englisch ) ) USW
Und du hast mit deinem Beispiel vollkommen recht. Sowas wäre indiskutabel. Ich bin halt der Meinung dass wir uns viel Zeit und Geld sparen könnten, wenn man den Standard kennen und nutzen würde. Z. B. Hat eine Berater Firma bei uns einen RFC-FuBa gebaut, der aber im Prinzip genauso im Standard schon als Bapi existiert. ( Bloß, dass der Bapi mehr informationen zurück liefert )
Dann hoffe ich mal, dass ich meinen Chef da überzeugen kann, dass man so eine Stelle einrichten kann
Leider müssen wir die nächsten 10 Jahre die Ungarische Notation noch durchlassen, bin selber auch kein Fan davon.
Ich habe im SCI es tatsächlich soweit hinbekommen, dass bei der UN eine Warnung erscheint, blockieren kommt später.
Aber du hast recht, man kann nicht alles automatisieren, man kann es aber soweit es geht versuchen! z. B. Dokumentation. Wir haben eine Schnittstelle, die uns einerseits die Doku im SAP System direkt liefert und die Dokumentation die wir im Sol-Man anhängen. Erst wenn beides vorhanden ist ( und die SAP Doku gewisse Bereiche abdeckt ) wird der Transport durchgelassen. ( zumindest ist das der Plan ) Oder halt andere Themen, die man leichter automatisieren kann ( Übersetzungen - prüfen ob eine vorhanden ist --> alle Übersetzungen zu manuell zu prüfen würde gar nicht gehen ... sonst müsste ich 3 Sprachen zusätzlich zu deutsch und englisch sprechen ( im HCM Bereich reicht es bei uns, wenn ich den namen des programms nehme und daraus dann das land und die jeweilige übersetzung lese ) - oder kommentare prüfen ob sie englisch sind oder eben nicht ( vorgabe ist natürlich englisch ) ) USW
Und du hast mit deinem Beispiel vollkommen recht. Sowas wäre indiskutabel. Ich bin halt der Meinung dass wir uns viel Zeit und Geld sparen könnten, wenn man den Standard kennen und nutzen würde. Z. B. Hat eine Berater Firma bei uns einen RFC-FuBa gebaut, der aber im Prinzip genauso im Standard schon als Bapi existiert. ( Bloß, dass der Bapi mehr informationen zurück liefert )
Dann hoffe ich mal, dass ich meinen Chef da überzeugen kann, dass man so eine Stelle einrichten kann
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Warum? Wer was anfasst, macht die UN raus, das dauert ja nicht lang.SaskuAc hat geschrieben:Ich finde die Einstellung gut!
Leider müssen wir die nächsten 10 Jahre die Ungarische Notation noch durchlassen
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Unnötiger Aufwand, da "Keine Variablennamensregeln" eine Obermenge von HN ist.ralf.wenzel hat geschrieben:Warum? Wer was anfasst, macht die UN raus, das dauert ja nicht lang
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Wer spricht von "keine Regeln"? Ich nicht.
Edit: Eine Änderung von lt_ekko in purch_order_headers (wenn es denn Bestellungen sind) ist kein Zeichen von Regelfreiheit. Die Entfernung eines g-Präfixes (das fachlich falsch ist, weil es keine globalen Daten im SAP gibt) auch nicht.
Ralf
Edit: Eine Änderung von lt_ekko in purch_order_headers (wenn es denn Bestellungen sind) ist kein Zeichen von Regelfreiheit. Die Entfernung eines g-Präfixes (das fachlich falsch ist, weil es keine globalen Daten im SAP gibt) auch nicht.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Naja - Ansichtssache.
1.) Wenn es schon lt_purch_order_headers heißt wüsste ich nicht was das Weglassen des "lt_" jetzt an Klarheit bringen sollte. Da es eine hinreichend große Anhängerschaft der HN gibt hilft der lange Name allen Fraktionen - bis auf die HN-Hasser.
2.) Und ganz speziell hier: Wenn ich eine Tabelle habe die ein paar vollsttändige EKKO-Zeilen beherbergt halte ich lt_ekko für einen sehr guten Namen - auch wenn es sich um Bestellköpfe handelt. Denn gerade wenn du mal einen nicht ganz so trivialen Fall nimmst - wie müssten denn nach deiner Logik Tabellen wie lt_vbak oder lt_afko genannt werden?
1.) Wenn es schon lt_purch_order_headers heißt wüsste ich nicht was das Weglassen des "lt_" jetzt an Klarheit bringen sollte. Da es eine hinreichend große Anhängerschaft der HN gibt hilft der lange Name allen Fraktionen - bis auf die HN-Hasser.
2.) Und ganz speziell hier: Wenn ich eine Tabelle habe die ein paar vollsttändige EKKO-Zeilen beherbergt halte ich lt_ekko für einen sehr guten Namen - auch wenn es sich um Bestellköpfe handelt. Denn gerade wenn du mal einen nicht ganz so trivialen Fall nimmst - wie müssten denn nach deiner Logik Tabellen wie lt_vbak oder lt_afko genannt werden?
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ich habe gerade ein Projekt, bei dem die Benamung von Variablen total inkonsistent ist, weil man ständig an Längengrenzen stößt. Außerdem: Da es keine globalen Daten im SAP gibt, ist das l schon Quatsch. Sonst müsstest du bei einer Variable auch davorschreiben, dass es sich um eine Variable handelt.
EKKO-Zeilen können alles mögliche sein. Rahmenverträge, Bestellungen, etc. Nach irgendeinem Kriterium werden die ja wohl in die interne Tabelle geschrieben worden sein - und genau das gehört in den Namen. Dann weiß ich auch, was drin ist. Will ich das wissen, muss ich das ganze Programm nach der Befüllung der Tabelle absuchen, wenn es nicht im Namen steht. Aber klar, Hauptsache lt_ steht davor, drei Zeichen für eine Nicht-Information.
Ralf
EKKO-Zeilen können alles mögliche sein. Rahmenverträge, Bestellungen, etc. Nach irgendeinem Kriterium werden die ja wohl in die interne Tabelle geschrieben worden sein - und genau das gehört in den Namen. Dann weiß ich auch, was drin ist. Will ich das wissen, muss ich das ganze Programm nach der Befüllung der Tabelle absuchen, wenn es nicht im Namen steht. Aber klar, Hauptsache lt_ steht davor, drei Zeichen für eine Nicht-Information.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Nicht schon wieder dieser Unsinn. Erstens gibt sehr wohl globale Variablen- und zwar bezogen auf den Program-Load. Zweitens gibt es a) so was wie Verschattungen oder viel schlimmer b) wenn man vergisst eine (lokale) Variable zu definieren und es die leider im globalen Kontext schon gibt kommt man in Teufels Küche. Und drittens verstehe ich einfach nicht, warum du so unflexibel bist, dass du es nicht schaffst über die ersten 2-3 Buchstaben einer HN hinwegzusehen um den Rest des Variablennamens zu interpretieren. Wenn es Kollegen von mir leichter fällt HN zu lesen schreibe ich HN ( die sollen das schließlich später warten ) - wenn sie besser nicht-HN lesen können schreibe ich halt so. Der Compiler/Interpreter weiß eh was du meinst - da geht es eher darum den anderen Kollegen die Arbeit so leicht wie möglich zu machenralf.wenzel hat geschrieben:Außerdem: Da es keine globalen Daten im SAP gibt, ist das l schon Quatsch.
Ist dir schon mal der Gedanke gekommen, dass es bei einem Programm implizit klar sein könnte ( weil es z.B. im Klassennamen steht ) ob es sich um Rahmenverträge, Bestellungen oder was auch immer handelt und dass man es nicht explizit angeben muss? Oder dass es evtl. wichtig sein könnte die Quelle der Daten anzugeben ( EKKO )? Nicht jeder denkt so wie du, Ralf - aber das heißt nicht, dass alle anderen Idioten sind, deren Ansätze schon mal per se nix taugen weil sie nicht von dir sind.ralf.wenzel hat geschrieben:EKKO-Zeilen können alles mögliche sein. Rahmenverträge, Bestellungen, etc. Nach irgendeinem Kriterium werden die ja wohl in die interne Tabelle geschrieben worden sein - und genau das gehört in den Namen. Dann weiß ich auch, was drin ist. Will ich das wissen, muss ich das ganze Programm nach der Befüllung der Tabelle absuchen, wenn es nicht im Namen steht. Aber klar, Hauptsache lt_ steht davor, drei Zeichen für eine Nicht-Information.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Unit605
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Pass mal auf. Hier wird nach Meinungen gefragt und das ist meine. Wenn sie dir nicht passt, lies sie einfach nicht. Ich habe sie (siehe Link in der Signatur) mehrfach mit verschiedenen Ansätzen schlüssig begründet.
Wenn meine Meinung hier nicht gefragt ist, kann ich meinen User gern löschen und das Posten einstellen.
Ich soll hier ständig Rücksicht nehmen auf die Befindlichkeiten anderer. Auf mich nimmt auch keiner Rücksicht.
Zum letzten Mal: "Global" ist ein absoluter Begriff. Eine globale Klasse (auch ein Datentypen) ist systemweit verfügbar. Dieses Kriterium erfüllt KEINE Variable, also gibt es keine globalen Variablen. Klar kann ich "global" auf was anderes beziehen als auf das, was man darunter versteht, dann ist HN globaler Unfug (global auf mich bezogen) und ganz toll (global auf dich bezogen). Und zur Benamung nochmal: Ich diskutiere hier den allgemeinen Fall. Dass es IMMER Spezialfälle gibt, liegt auf der Hand. Für ein Materialdaten-Migrations-Framework habe ich lauter Tabellennamen verwendet, von denen ich hier abrate. Also komm mir bitte nicht mit "aber wenn dies und das und jenes zutreffen". Wir machen hier keine Fließbandarbeit.
Ich schaue oft und gern über den Tellerrand und erlebe gerade bei Leuten, die aus anderen Welten der Softwareentwicklung kommen, völliges Unverständnis für die im SAP üblichen Präfixe. Und "mal HN und mal nicht" ist kein definierter Standard. Einen Schaltplan, der von mehreren Leuten erstellt wird, wirst du auch nicht "mal kursiv, mal nicht" beschriftet sehen (auch wenn beides Normschrift ist). Wenn das einer sieht, sagt er wie es alle machen sollen, weil Einheitlichkeit eine Reihe von Vorteilen hat.
So, nochmal: Willst du meine Meinung nicht wissen, ignoriere sie bitte. Aber ich lasse mich hier nicht als Arsch vom Dorf hinstellen, der nur * schreibt. Man könnte meine durch Fakten schlüssig belegte Meinung einfach mal akzeptieren. (Zur HN höre ich immer nur, es fiele Leuten leichter. Deutsch fällt vielen auch leichter als englisch, trotzdem sollten Variablen englisch sein).
Wenn man das (Akzeptieren) nicht will, kann ich auch gehen!!
Ralf *sauer
Edit für alle die, die fünf Jahre nicht aufgepasst haben: Sog. "globale" Variablen sind OBSOLET, weil intransparent. Schon deshalb sollten sie in einer gescheiten Anwendung gar nicht vorkommen. Und WENN sie unvermeidbar sind, kann man sie so kapseln, dass man sie nicht direkt verwendet.
Wenn meine Meinung hier nicht gefragt ist, kann ich meinen User gern löschen und das Posten einstellen.
Ich soll hier ständig Rücksicht nehmen auf die Befindlichkeiten anderer. Auf mich nimmt auch keiner Rücksicht.
Zum letzten Mal: "Global" ist ein absoluter Begriff. Eine globale Klasse (auch ein Datentypen) ist systemweit verfügbar. Dieses Kriterium erfüllt KEINE Variable, also gibt es keine globalen Variablen. Klar kann ich "global" auf was anderes beziehen als auf das, was man darunter versteht, dann ist HN globaler Unfug (global auf mich bezogen) und ganz toll (global auf dich bezogen). Und zur Benamung nochmal: Ich diskutiere hier den allgemeinen Fall. Dass es IMMER Spezialfälle gibt, liegt auf der Hand. Für ein Materialdaten-Migrations-Framework habe ich lauter Tabellennamen verwendet, von denen ich hier abrate. Also komm mir bitte nicht mit "aber wenn dies und das und jenes zutreffen". Wir machen hier keine Fließbandarbeit.
Ich schaue oft und gern über den Tellerrand und erlebe gerade bei Leuten, die aus anderen Welten der Softwareentwicklung kommen, völliges Unverständnis für die im SAP üblichen Präfixe. Und "mal HN und mal nicht" ist kein definierter Standard. Einen Schaltplan, der von mehreren Leuten erstellt wird, wirst du auch nicht "mal kursiv, mal nicht" beschriftet sehen (auch wenn beides Normschrift ist). Wenn das einer sieht, sagt er wie es alle machen sollen, weil Einheitlichkeit eine Reihe von Vorteilen hat.
So, nochmal: Willst du meine Meinung nicht wissen, ignoriere sie bitte. Aber ich lasse mich hier nicht als Arsch vom Dorf hinstellen, der nur * schreibt. Man könnte meine durch Fakten schlüssig belegte Meinung einfach mal akzeptieren. (Zur HN höre ich immer nur, es fiele Leuten leichter. Deutsch fällt vielen auch leichter als englisch, trotzdem sollten Variablen englisch sein).
Wenn man das (Akzeptieren) nicht will, kann ich auch gehen!!
Ralf *sauer
Edit für alle die, die fünf Jahre nicht aufgepasst haben: Sog. "globale" Variablen sind OBSOLET, weil intransparent. Schon deshalb sollten sie in einer gescheiten Anwendung gar nicht vorkommen. Und WENN sie unvermeidbar sind, kann man sie so kapseln, dass man sie nicht direkt verwendet.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Langsam wird mir klar wo dein Problem liegt - du verwendest eine eigene Definition von "globale Variable" und nicht diejenige, die üblicherweise im Kontext von Programmiersprachen verwendet wird.ralf.wenzel hat geschrieben:Zum letzten Mal: "Global" ist ein absoluter Begriff. Eine globale Klasse (auch ein Datentypen) ist systemweit verfügbar. Dieses Kriterium erfüllt KEINE Variable, also gibt es keine globalen Variablen.
- https://en.wikipedia.org/wiki/Global_variable hat geschrieben:In computer programming, a global variable is a variable with global scope, meaning that it is visible (hence accessible) throughout the program, unless shadowed.
- https://de.wikipedia.org/wiki/Variable_(Programmierung)#Sichtbarkeitsbereich_von_Variablen_.28Scope.29 hat geschrieben:Ein wichtiges Konzept von Programmiersprachen ist das Unterprogramm, ob es nun Prozedur, Funktion, Methode oder noch anders heißt. Die allgemeinste Form dieses Konzepts ist der in der Programmiersprache ALGOL 60 erstmals eingeführte Block. Praktisch alle Programmiersprachen, die dieses Konzept in irgendeiner Form anbieten, erlauben es, dass Blöcke ihre eigenen Variablen besitzen, die sich von den Variablen anderer Blöcke eindeutig unterscheiden lassen. Solche Variablen heißen lokale Variablen. Eine Variable, die im ganzen Programm für alle Blöcke zur Verfügung steht, heißt globale Variable.
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
1.) Wenn ich den rot markiertem Teil anschaue frage ich mich, warum du dich wunderst wenn man dich darauf hinweist Rücksicht zu nehmen?ralf.wenzel hat geschrieben:Edit für alle die, die fünf Jahre nicht aufgepasst haben: Sog. "globale" Variablen sind OBSOLET, weil intransparent. Schon deshalb sollten sie in einer gescheiten Anwendung gar nicht vorkommen. Und WENN sie unvermeidbar sind, kann man sie so kapseln, dass man sie nicht direkt verwendet.
2.) Die Worte "obsolet" und "unvermeidbar" sind eine Tautologie.
3.) Ralfs grundsätzliche Aussage hingegen ist durchaus valide:
https://en.wikipedia.org/wiki/Global_variable#Use hat geschrieben:They [global variables] are usually considered bad practice precisely because of their non-locality: a global variable can potentially be modified from anywhere (unless they reside in protected memory or are otherwise rendered read-only), and any part of the program may depend on it. A global variable therefore has an unlimited potential for creating mutual dependencies, and adding mutual dependencies increases complexity. See action at a distance. Global variables also make it difficult to integrate modules because software written by others may use the same global names unless names are reserved by agreement, or by naming convention. However, in a few cases, global variables can be suitable for use. For example, they can be used to avoid having to pass frequently-used variables continuously throughout several functions. In practice, large programs may well require a large number of global variables because there are so many parameters that are shared between different functions, and care must be taken to make sure different functions share the global data without mishap.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Der rot markierte Satz steht da so, weil das schon seit Jahren so gilt, offensichtlich aber von einigen fröhlich weiterverwendet wird.
Obsolet heißt "nicht mehr gebräuchlich", unvermeidbar kann es z. B. bei Dynpros sein. Ja, ich habe auch schon Klassenattribute dafür eingesetzt, aber das birgt viele Fehlerquellen in sich (z. B. wird nicht mehr gefragt, in der DDIC-Typ als Basis herangezogen werden soll, auch wenn das Attribut auf einem basiert). Es wird nichtmal verprobt, ob es das Attribut überhaupt gibt.
Ich hab so mal einen Tippfehler suchen müssen (bzw. einen Fehler, der sich als Tippfehler herausstellte), da wird man bekloppt.
Ralf
Obsolet heißt "nicht mehr gebräuchlich", unvermeidbar kann es z. B. bei Dynpros sein. Ja, ich habe auch schon Klassenattribute dafür eingesetzt, aber das birgt viele Fehlerquellen in sich (z. B. wird nicht mehr gefragt, in der DDIC-Typ als Basis herangezogen werden soll, auch wenn das Attribut auf einem basiert). Es wird nichtmal verprobt, ob es das Attribut überhaupt gibt.
Ich hab so mal einen Tippfehler suchen müssen (bzw. einen Fehler, der sich als Tippfehler herausstellte), da wird man bekloppt.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Jetzt hört's halt auf, bis einer weint... 
mich würde jetzt nur ein link zur korrekten Darstellung von Variablen interessieren. Ich gehe mal davon aus das HN und UN das gleiche bedeuten (ungarische oder hungarian Notatition), habe bisher auch meine Variablen mit l+<typ> benannt, (auch lt_ekko weil ich dann weis woher die Daten stammen, unter Umsatänden dann noch lt_ekko_po etc. für Differenzierung). Das G_ habe ich weggelassen weil alles was nicht lokal definiert ist kann war dann eben global(soweit das nötig ist)
Habe nur diesen link gefunden: https://help.sap.com/http.svc/rc/abapdo ... _guidl.htm
oder gibt es da noch ausführlichere Information?
Danke und Gruß aus dem Urlaub in Portugal,
Wolfgang
mich würde jetzt nur ein link zur korrekten Darstellung von Variablen interessieren. Ich gehe mal davon aus das HN und UN das gleiche bedeuten (ungarische oder hungarian Notatition), habe bisher auch meine Variablen mit l+<typ> benannt, (auch lt_ekko weil ich dann weis woher die Daten stammen, unter Umsatänden dann noch lt_ekko_po etc. für Differenzierung). Das G_ habe ich weggelassen weil alles was nicht lokal definiert ist kann war dann eben global(soweit das nötig ist)
Habe nur diesen link gefunden: https://help.sap.com/http.svc/rc/abapdo ... _guidl.htm
oder gibt es da noch ausführlichere Information?
Danke und Gruß aus dem Urlaub in Portugal,
Wolfgang
Geht nicht gibts nicht
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
1427
Views
Views
0
Antw.
Antw.
1347
Views
Views
Wie erkennt man im Org-Management Wurzeln
von donny » 02.03.2007 09:19 • Verfasst in Human Resources
von donny » 02.03.2007 09:19 • Verfasst in Human Resources
1
Antw.
Antw.
1665
Views
Views
0
Antw.
Antw.
1205
Views
Views
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.