Dynamische Programmierung

Re: Dynamische Programmierung

ZF_SAPler hat geschrieben: ↑

17.09.2022 13:28

gtoXX hat geschrieben: ↑

17.09.2022 12:54

"event methode ON_DOUBLECLICK
FIELD-SYMBOLS: <ft_result> TYPE STANDARD TABLE.
ASSIGN mt_result->* TO <ft_result>. " HIER FEHLEN mir die Daten um weiterzumachen

Natürlich fehlen sie dir da. Du bist ja in einem ganz anderen Objekt. Nämlich diesem "lo_obj TYPE REF TO zcL( )." Woher soll das Objekt dein "mt_result->*" kennen ?

Danke, hätte ich mir denken können!

Gerne doch.

Re: Dynamische Programmierung

ralf.wenzel hat geschrieben: ↑

17.09.2022 13:46

gtoXX hat geschrieben: ↑

17.09.2022 13:35

Ja es ist ja immer alles etwas fallspezifisch. In dem Fall ist es eine Absicherung, falls für Kundenentwicklungen innerhalb der Produkte das nötig ist, wenn sie vererbt werden. Die Sichtbarkeit nachträglich zu ändern ohne sich dessen bewusst zu sein könnte auch Komplikationen mit sich bringen. In jedem Fall so oder so .. never public.

Ah, Produktentwicklung. Dann verstehe ich das sogar. Das ist noch etwas anderes als Individualentwicklung.


Ralf

Definitiv. Wobei es mancher Individualentwicklung nicht schadet zumindest mehr Brain zu versuchen. Und ja ungarische Notation ist auch absolut verboten. Auch durch deine Anregung.

Re: Dynamische Programmierung

gtoXX hat geschrieben: ↑

17.09.2022 16:07

ralf.wenzel hat geschrieben: ↑

17.09.2022 13:46

gtoXX hat geschrieben: ↑

17.09.2022 13:35

Ja es ist ja immer alles etwas fallspezifisch. In dem Fall ist es eine Absicherung, falls für Kundenentwicklungen innerhalb der Produkte das nötig ist, wenn sie vererbt werden. Die Sichtbarkeit nachträglich zu ändern ohne sich dessen bewusst zu sein könnte auch Komplikationen mit sich bringen. In jedem Fall so oder so .. never public.

Ah, Produktentwicklung. Dann verstehe ich das sogar. Das ist noch etwas anderes als Individualentwicklung.


Ralf

Definitiv. Wobei es mancher Individualentwicklung nicht schadet zumindest mehr Brain zu versuchen. Und ja ungarische Notation ist auch absolut verboten. Auch durch deine Anregung.

Kannst du bitte erläutern, was deiner Meinung nach eine bessere Notation wäre?
Ich hatte immer
lv_*
ls_*
lt_*
für lokale Sachen und für globale statt dem l ein g.

importparameter iv, is, it
exportparameter ev, es, et
returning rv, rs, rt

Bei Objekten bin ich unsicher..

Bei Objektattributen werde ich mir merken, dass mit _NAME.

Re: Dynamische Programmierung

ZF_SAPler hat geschrieben: ↑

17.09.2022 16:30

gtoXX hat geschrieben: ↑

17.09.2022 16:07

ralf.wenzel hat geschrieben: ↑

17.09.2022 13:46

Ah, Produktentwicklung. Dann verstehe ich das sogar. Das ist noch etwas anderes als Individualentwicklung.


Ralf

Definitiv. Wobei es mancher Individualentwicklung nicht schadet zumindest mehr Brain zu versuchen. Und ja ungarische Notation ist auch absolut verboten. Auch durch deine Anregung.

Kannst du bitte erläutern, was deiner Meinung nach eine bessere Notation wäre?
Ich hatte immer
lv_*
ls_*
lt_*
für lokale Sachen und für globale statt dem l ein g.

importparameter iv, is, it
exportparameter ev, es, et
returning rv, rs, rt

Bei Objekten bin ich unsicher..

Bei Objektattributen werde ich mir merken, dass mit _NAME.

Wie Ralf geschrieben hat, hat er einen guten Artikel darüber geschrieben.

Der wichtigste Punkt -> Namenskonventionen sollten von allen Entwicklern gleich genutzt werden und auch Vorgabe für externe Entwickler sein.

Ein kleines Beispiel :

METHOD alpha IMPORTING IM_WERT TYPE i
EXPORTING EX_WERT TYPE i
CHANGING CH_WERT TYPE i
RETURNING VALUE(RE_WERT) TYPE i.

Hier ist innerhalb der Methode klar erkennbar was, welche Aufgabe hat und zu beachten ist z.b. bei Exporting.

Ein paar Präfixe nutzen wir zur Unterscheidung schon, auch wenn es nicht zwingend nötig wäre.

Wie OBJ_, TAB_, DAT_ . Ansonsten sollte der Rest immer möglichst sprechend sein.

tab_material_masterdata merkt sich besser als MARA etc.