Diesen Artikel habe ich ursprünglich im SAP Community Network veröffentlicht.

Wie im vorherigen Beitrag ist auch dieser eine Fallstrick, den eher die Entwickler von Frameworks und Toolkits als deren Nutzer betrifft.

Der Datentyp STRING ist in ABAP seit 4.6A verfügbar (wie viele von Ihnen erinnern sich übrigens daran, an diesem Release gearbeitet zu haben?), und viele Entwickler scheinen Strings als die einzige Möglichkeit zu betrachten, textähnliche Daten in einem ABAP-Programm zu transportieren. Ich kann nur über die Gründe spekulieren – vielleicht liegt es daran, dass ABAP für die meisten Entwickler nicht die erste Programmiersprache ist und in anderen Sprachen Strings das gängige Instrument zur Verarbeitung von Textdaten sind. Einige langjährige ABAP-Entwickler könnten auch auf Strings umgestiegen sein, weil sie einfacher zu verwenden sind als die herkömmlichen C-Felder – man muss nicht mehr über die maximale Länge des Wertes nachdenken. In vielen Programmen und Frameworks habe ich das folgende Muster gesehen:

METHODS: do_something IMPORTING i_text TYPE string.

Verstehen Sie mich nicht falsch – es ist nichts Schlechtes daran, STRINGs dort zu verwenden, wo sie angebracht sind, aber in vielen Fällen sind sie nicht erforderlich und können die Benutzer Ihres Frameworks sogar verärgern. Zum Beispiel können die folgenden Aufrufe verwendet werden …

DATA: l_string TYPE string VALUE 'Foo Bar'.  
lr_instance->do_something( 'Foo Baz' ).  
lr_instance->do_something( `     Bar Baz     ` ). " my preciousss spacesss  
lr_instance->do_something( l_string ).  </pre>

…einige andere, eher gängige Parametertypen funktionieren nicht:

TYPE-POOLS icon.  
DATA: l_text TYPE c LENGTH 100.  
lr_instance->do_something( l_text ).  
lr_instance->do_something( 'Foo Bar'(001) ).  
lr_instance->do_something( icon_red_light ).

Man könnte argumentieren, dass dies ein Problem der impliziten Typkonvertierung ist, die einige gängige Fälle nicht verarbeiten kann, aber für diejenigen von uns, die die Sprache selbst nicht anpassen können, ist das kein Trost. Die Notwendigkeit, diese Einschränkung zu umgehen, erhöht unweigerlich den Blutdruck des Entwicklers und führt zu wirklich chaotischem Code wie diesem:

DATA: lr_function TYPE REF TO cl_salv_function,  
      l_string    TYPE string.  

* ...  

l_string = 'Baz Bar'(042).  
lr_function->set_text( l_string ).  
l_string = icon_red_light.  
lr_function->set_icon( l_string ).  
l_string = 'Tooltime Fooltime'(084).  
lr_function->set_tooltip( l_string ).

Glücklicherweise gibt es eine einfache Faustregel, um dies zu vermeiden: Verwenden Sie für IMPORTING-Parameter CSEQUENCE als Typ, es sei denn, Sie benötigen wirklich einen STRING. Sie können weiterhin STRING-Variablen und -Attribute verwenden, um die Daten intern zu verarbeiten, aber die Benutzer Ihrer Methode können den Datentyp, der an den tatsächlichen Parameter übergeben wird, frei wählen.

Wie Sie im obigen Beispiel sehen können, ist dies ein recht häufiges Problem. Selbst im SALV-Framework finden Sie Methoden, bei denen Sie eine manuelle Typkonvertierung durchführen müssen. Da dies jedoch leicht zu vermeiden ist, denken Sie bitte sowohl an die binären Kätzchen als auch an die Herzkranzgefäße Ihrer Entwicklerkollegen und wählen Sie Ihre Parametertypen mit Bedacht aus.