Wann sollte man LIKE verwenden

Wann sollte man LIKE verwenden

Man kann eine Typisierung mittels LIKE verwenden, um sein Coding robuster gegenüber zu machen. Oftmals braucht man lokale Hilfsvariablen. Zum Beispeil möchte man über eine Tabelle loopen, die als Parameter in eine Routine eingeht, und benötigt eine Workarea. In diesem Fall kann die Workarea relativ einfach deklarieren: Falls sich der Typ der Tabelle itab ändert, bleibt die Implementierung der Routine unbeeinflußt. Der Typ von wa und tmp_itab wird ja "relativ" zum Parameter itab bestimmt.

Re: Ja, aber...

Haubi hat geschrieben:Wenn ich allerdings untypisierte Parameter in einem Programm sehe könnte ich immer an der Wand hochgehen .

Die Typisierung von FORM-Schnittstellen wurde zu 3.0 eingeführt, wenn ich mich richtig erinnere.
Zu 3.0 gab es in der SE38 auch noch einen Menüpunkt Hilfsmittel->Typisierung, der das Programm RSPARM30 gestartet hat.
Das Programm untersuchte im angegebenen Rahmenprogramm alle FORMs mit untypisierten Parametern, suchte nach passenden PERFORM-Anweisungen, analysierte die Herkunft und Typisierung der Aktualparameter und generierte Vorschläge f'ür die Typisierung.
In der Liste konnte man dann per Checkbox angeben, welche Typisierung das Programm vornehmen sollte. Beim Sichern hat das Programm automatisch die FORM-Schnittstellen angepaßt.
Aber kaum ein Kunde wußte von dieser Funktion.
Zu 4.0 wollte ich das Programm noch mal verwenden.

Der Menüpunkt war verschwunden, aber das Programm existierte noch.
Im Programm habe ich dann 2 Fehler entdeckt:
1. die Prüfung, ob es externe PERFORMs gibt, war fehlerhaft.
2. Wenn das Programm auf Aktualparameter gestoßen ist, die per STATICS definiert wurden, kam es zum Fehler.
Die falsche Prüfung auf externe Performs hat SAP in einem Patch für 3.1I behoben, das Problem mit STATICS-Anweisungen nicht.
Also habe ich RSPARM30 nach ZSPARM30 kopiert, die Includes, die verändert werden mußten, ebenfalls kopiert und in meinem Rahmenprogramm ersetzt, den Rest übernommen.
Mit irgendeinem späteren Release wurden dann alle Restbestände von RSPARM30 entsorgt, so daß auch mein ZSPARM30 ohne die Includes nicht mehr funktionierte.
Und alles from scratch noch mal zu programmieren war mir dann doch zu viel Aufwand.

Generell sollte man LIKE nicht mehr verwenden, da es im Zusammenhang mit ABAP Objects verboten ist (oder mit einer der nächsten Versionen verboten wird).

Daher also besser:

Code: Alles auswählen.

FORM f USING ut_itab TYPE itab_type.
DATA: ls_wa TYPE LINE OF itab_type
    , lt_itab TYPE itab_type.
...

Auch ohne ABAP Objects kann es schon zu 4.6 zu Problemen kommen, wenn man LIKE verwendet.
Ich hab das mal beim Upgrade von 4.6B auc 4.6C gesehen.
In Kundenprogrammen, in denen z.B. vorkam, gab es einen Syntaxfehler, nachdem SAP an die DDIC-Struktur weitere Komponenten angehängt hatte, so daß die Struktur plötzlich keine flache Struktur mehr war.
(Das verwendete Feld selbst war aber nach wie vor CHAR.)

Ist jemand "mutig" und definiert eine APPEND-Struktur für SYST, in der dann ein Tabellentyp als Komponente verwendet wird?
Wie oft kommt wohl DATA: rc LIKE SYST-SUBRC und ähnliches in Programmen vor?
Und ob der Fehler auch auf LIKE SY-SUBRC durchschlägt?
Neugierig bin ich ja. Noch möchte ich mir mein WAS Linux TestDrive aber nicht kaputtmachen.
Evtl. zerlege ich aber demnächst das MiniWAS. Dann berichte ich mal.

Frank

Auszug aus der F1-Hilfe zum TYPE-Befehl (Zusatz 2 ... like F )

Hinweis
In vielen Fällen ist es sehr empfehlenswert, diesen Zusatz zu verwenden. Typänderungen von Feldern, auf die man sich bezieht, bekommt das Programm automatisch mit. Außerdem werden ggf. keine unnötigen und evtl. auch ungewollten Konvertierungen durchgeführt.

bzw. fast genauso der Hinweistext in der F1-Hilfe zum DATA-Befehl:

Wann immer sinnvoll, sollte man diesen Zusatz verwenden. Typänderungen von Feldern, auf die man sich bezieht, werden vom ABAP-Laufzeitsystem automatisch berücksichtigt. Außerdem werden keine unnötigen und evtl. auch ungewollten Konvertierungen durchgeführt.

wobei hier natürlich zu fragen ist, was genau mit "Wann immer sinnvoll" wohl gemeint ist.


@Frank:
Dein Beispiel mit dem Problem einer LIKE-Referenzierung nachdem SAP ein Standardfeld geändert hat ist wohl berechtigt, aber meinst du nicht, dass genau dasselbe Problem auftauchen kann, wenn SAP (oder man selber) in einem Tabellenfeld das Datenelement ändert, z.B. von integer nach numc oder die Länge eines C-Feldes ein wenig erweitert?

Und auch wenn ich mich hier zum Anfänger erkläre: Ich krieg es einfach nicht hin das im folgenden Coding liegende LIKE durch ein äquivalentes TYPE zu ersetzen.

Soso,

endlich mal jemand der mich erleuchtet.

Die Info ist so interessant, dass mich eigentlich noch mehr interessiert, wo das denn in der Doku steht - normalerweise frage ich solche Fragen nämlich nicht sondern suche die Antwort selber, aber da hatte ich nix gefunden.