Programmbeurteilung: Textpool durchsuchen
8 Beiträge
•
Seite 1 von 1
8 Beiträge
Seite 1 von 1
Hallo zusammen,
ich hab einen Report geschrieben, der den Textpool durchsucht.
Das Programm funktioniert - so weit, so gut.
Da ich ABAP Anfänger bin, bitte ich mal um konstruktive Kritik.
Was ist wie besser zu machen?
Danke,
Murdock.
ich hab einen Report geschrieben, der den Textpool durchsucht.
Das Programm funktioniert - so weit, so gut.
Da ich ABAP Anfänger bin, bitte ich mal um konstruktive Kritik.
Was ist wie besser zu machen?
Code: Alles auswählen.
REPORT ztext_suche LINE-SIZE 255.
TYPES: BEGIN OF ty_progs,
name TYPE trdir-name,
* id type textpool-id,
key TYPE textpool-key,
entry TYPE textpool-entry,
END OF ty_progs.
DATA: gt_text_read TYPE TABLE OF textpool,
gt_prog_found TYPE TABLE OF ty_progs, "Fundstellen
gt_prog_read TYPE TABLE OF trdir-name, " Alle Programmnamen
gv_prog_name TYPE trdir-name,
gs_prog_found TYPE ty_progs.
FIELD-SYMBOLS: <fs_prog> TYPE trdir-name,
<fs_text> TYPE textpool,
<fs_text_found> TYPE ty_progs.
PARAMETER: p_text TYPE trdir-name.
SELECT-OPTIONS: s_prog FOR gv_prog_name.
START-OF-SELECTION.
* Alle Programmnamen lesen
SELECT name
INTO TABLE gt_prog_read
FROM trdir
WHERE name IN s_prog.
* Textpool von den einzelnen Programmen lesen
LOOP AT gt_prog_read ASSIGNING <fs_prog>.
READ TEXTPOOL <fs_prog> INTO gt_text_read LANGUAGE 'D'.
* Tab. mit Textpool durchsuchen
LOOP AT gt_text_read ASSIGNING <fs_text> WHERE entry CP p_text.
* Wenn gefunden, dann Daten in die "gefunden" Struktur schieben
MOVE-CORRESPONDING <fs_text> TO gs_prog_found.
* Um Programmnamen anreichern
gs_prog_found-name = <fs_prog>.
* An die Tabelle für gefundene Textstellen anhängen
APPEND gs_prog_found TO gt_prog_found.
CLEAR gs_prog_found.
ENDLOOP. "loop at gt_text_read
ENDLOOP. "LOOP at gt_prog_read
UNASSIGN <fs_prog>.
UNASSIGN <fs_text>.
* Ausgabe
LOOP AT gt_prog_found ASSIGNING <fs_text_found>.
WRITE: / <fs_text_found>-name(40), <fs_text_found>-key, <fs_text_found>-entry(60).
ENDLOOP. "LOOP at gt_prog_found
UNASSIGN <fs_text_found>.
END-OF-SELECTION.
Murdock.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Sieht doch gut aus.
Aenderungen sind wohl nur "Vorlieben" des einzelnen Developers.
END-OF-SELECTION. <--- wird nicht benoetigt. Nur bei Verwendung einer logischer Datenbank
Aenderungen sind wohl nur "Vorlieben" des einzelnen Developers.
END-OF-SELECTION. <--- wird nicht benoetigt. Nur bei Verwendung einer logischer Datenbank
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Hallo Murdock,
das sieht doch sehr gut aus was du da hast. Sinnvolle Namensgebung, kommentiert, gut strukturiert...
Somit höchstens ein paar Kleinigkeiten die ich schöner fände.
1.) Statt "TYPE TABLE OF" das vollständige "TYPE STANDARD TABLE OF ... WITH NON-UNIQUE DEFAULT KEY"
2.) <fs...> ist eine Tautologie. Auch die Sichtbarkeit (global) ist nicht erkennbar.
3.) Das abschließende END-OF-SELECTION ist überflüssig. Da dies aber der Defaultzeitpunkt von ABAP ist, würde ich all dein Coding hinter END-OF-SELECTION statt hinter START-OF-SELECTION stellen. ( Und da dein Programm recht einfach strukturiert ist. Stelle nur deinen Select... hinter START-OF-SELECTION und den Rest hinter END-OF-SELECTION. Das ist zwar nicht der eigentliche Sinn dieser Zeitpunkte, aber könnte evtl. eine weitere Strukturierung des Programms darstellen ).
4.) Die UNASSIGNs sind überflüssig. Wir leben nicht mehr in Zeiten wo jedes Bit richtig Gold kostet.
5.) Jetzt muss ich schon suchen - aber was solls. Du wolltest es ja. Schönheitskorrektur: Die TYPEs der Feldsymboldefinitionen stehen nicht untereinander.
6.) Die Deklaration "PARAMETER" ist zwar erlaubt - aber offiziell heißt das "PARAMETERS"
7.) Reine Geschmackssache und ich kenne Andere, die so etwas aus anderen Überlegungen nicht machen würden. Deine Feldsymbole <fs_prog> und <fs_text> werden ledlich für deine LOOP ... ASSIGNING verwendet. In so einem Fall deklariere ich die Feldsymbole mittels "<...> LIKE LINE OF tabelle" um diesen Sachverhalt darzustellen.
8.) CLEAR gs_prog_found. ist wie 4.) theoretisch überflüssig in so einem kurzen Programm - aber für längere Programm ist eine Variableninitialisierung in Schleifen sehr löblich. Wenn ich aber einen CLEAR mache würde ich ihn immer an den Anfang meiner Vearbeitung denn ans Ende stellen (leichtere Lesbarkeit)
das sieht doch sehr gut aus was du da hast. Sinnvolle Namensgebung, kommentiert, gut strukturiert...
Somit höchstens ein paar Kleinigkeiten die ich schöner fände.
1.) Statt "TYPE TABLE OF" das vollständige "TYPE STANDARD TABLE OF ... WITH NON-UNIQUE DEFAULT KEY"
2.) <fs...> ist eine Tautologie. Auch die Sichtbarkeit (global) ist nicht erkennbar.
3.) Das abschließende END-OF-SELECTION ist überflüssig. Da dies aber der Defaultzeitpunkt von ABAP ist, würde ich all dein Coding hinter END-OF-SELECTION statt hinter START-OF-SELECTION stellen. ( Und da dein Programm recht einfach strukturiert ist. Stelle nur deinen Select... hinter START-OF-SELECTION und den Rest hinter END-OF-SELECTION. Das ist zwar nicht der eigentliche Sinn dieser Zeitpunkte, aber könnte evtl. eine weitere Strukturierung des Programms darstellen ).
4.) Die UNASSIGNs sind überflüssig. Wir leben nicht mehr in Zeiten wo jedes Bit richtig Gold kostet.
5.) Jetzt muss ich schon suchen - aber was solls. Du wolltest es ja. Schönheitskorrektur: Die TYPEs der Feldsymboldefinitionen stehen nicht untereinander.
6.) Die Deklaration "PARAMETER" ist zwar erlaubt - aber offiziell heißt das "PARAMETERS"
7.) Reine Geschmackssache und ich kenne Andere, die so etwas aus anderen Überlegungen nicht machen würden. Deine Feldsymbole <fs_prog> und <fs_text> werden ledlich für deine LOOP ... ASSIGNING verwendet. In so einem Fall deklariere ich die Feldsymbole mittels "<...> LIKE LINE OF tabelle" um diesen Sachverhalt darzustellen.
8.) CLEAR gs_prog_found. ist wie 4.) theoretisch überflüssig in so einem kurzen Programm - aber für längere Programm ist eine Variableninitialisierung in Schleifen sehr löblich. Wenn ich aber einen CLEAR mache würde ich ihn immer an den Anfang meiner Vearbeitung denn ans Ende stellen (leichtere Lesbarkeit)
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Murdock
@Unit605: Danke für's angucken und den Kommentar.
@black_adept: Danke für's die ausführlichen Kommentare.
Hast natürlich trotzdem Recht.
Danke und Gruß,
Murdock.
@black_adept: Danke für's die ausführlichen Kommentare.
Ok. Aber nur wegen der besseren Lesbarkeit, oder?black_adept hat geschrieben: 1.) Statt "TYPE TABLE OF" das vollständige "TYPE STANDARD TABLE OF ... WITH NON-UNIQUE DEFAULT KEY"
Das stimmt. Beides. Sollte ich hier im Betrieb mal anmerken, so steht's nämlich in unseren Entwicklungsrichtlinien.black_adept hat geschrieben: 2.) <fs...> ist eine Tautologie. Auch die Sichtbarkeit (global) ist nicht erkennbar.
Wer's dreckig macht, räumt auch wieder aufblack_adept hat geschrieben: 4.) Die UNASSIGNs sind überflüssig. Wir leben nicht mehr in Zeiten wo jedes Bit richtig Gold kostet.
Hast natürlich trotzdem Recht.black_adept hat geschrieben: 5.) Jetzt muss ich schon suchen - aber was solls. Du wolltest es ja. Schönheitskorrektur: Die TYPEs der Feldsymboldefinitionen stehen nicht untereinander.
Ach guck, wieder was gelernt.black_adept hat geschrieben: 6.) Die Deklaration "PARAMETER" ist zwar erlaubt - aber offiziell heißt das "PARAMETERS"
Das gefällt mir. Ich denke, das werde ich in Zukunft auch so machen.black_adept hat geschrieben: 7.) Reine Geschmackssache und ich kenne Andere, die so etwas aus anderen Überlegungen nicht machen würden. Deine Feldsymbole <fs_prog> und <fs_text> werden ledlich für deine LOOP ... ASSIGNING verwendet. In so einem Fall deklariere ich die Feldsymbole mittels "<...> LIKE LINE OF tabelle" um diesen Sachverhalt darzustellen.
Danke und Gruß,
Murdock.
Jein, es trainiert für ABAP-OO (da ist die Syntaxprüfung etwas strenger). SAP macht zwar aus TYPE TABLE OF impliziet ein TYPE STANDARD TABLE OF, aber es wird kein Schlüssel definiert. Für manche Dinge braucht man dann aber wieder diese Schlüsseldefinition z.B. wenn Deep-Structure definiert werden sollen.Murdock hat geschrieben:Ok. Aber nur wegen der besseren Lesbarkeit, oder?black_adept hat geschrieben: 1.) Statt "TYPE TABLE OF" das vollständige "TYPE STANDARD TABLE OF ... WITH NON-UNIQUE DEFAULT KEY"
Gruß Hendrik
Finde ich gutblack_adept hat geschrieben:Hallo Murdock,
Somit höchstens ein paar Kleinigkeiten die ich schöner fände.
1.) Statt "TYPE TABLE OF" das vollständige "TYPE STANDARD TABLE OF ... WITH NON-UNIQUE DEFAULT KEY"
7.) Reine Geschmackssache und ich kenne Andere, die so etwas aus anderen Überlegungen nicht machen würden. Deine Feldsymbole <fs_prog> und <fs_text> werden ledlich für deine LOOP ... ASSIGNING verwendet. In so einem Fall deklariere ich die Feldsymbole mittels "<...> LIKE LINE OF tabelle" um diesen Sachverhalt darzustellen.
Hast Du noch mehr von diesen semantischen Regeln?
Viele Grüße,
...entwickelnder Berater...beratender Entwickler
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
2995
Views
Views
2
Antw.
Antw.
2168
Views
Views
21
Antw.
Antw.
12618
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.