ABAP Trapdoors: Death By STRING

As in the previous post, this one is a trapdoor to be avoided by framework and toolkit designers rather than their users.

STRINGs are available in ABAP since 4.6A (how many of you remember working on that release, btw?), and many developers seem to think of STRINGs as the one and only way to transport text-like data around in an ABAP program. I can only speculate about the reasons – perhaps it’s because for most developers, ABAP isn’t the first programming language and in other languages, Strings are the common instrument to handle textual data. Some long-time ABAP developers might also have jumped on STRINGs  because they are easier to use than the traditional C fields – you don’t have to think about the maximum length of the value any more. In many programs and frameworks, I’ve seen the following pattern:

METHODS: do_something IMPORTING i_text TYPE string.

Don’t get me wrong – there’s nothing bad about using STRINGs where they are appropriate, but in many cases, they are not required and can even annoy the users of your framework. For example, while the following invocations can be used…

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 ).

…some other, rather common parameter types won’t work:

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 ).

One might argue that this is a problem of the implicit type conversion not being able to handle some common cases, but for those of us who can’t tweak the language itself, that’s no consolation. Having to work around this limitation invariably raises the blood pressure of the developer and leads to really messy code like this:

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 ).

Fortunately, there’s a simple rule of thumb to avoid this: For IMPORTING parameters, use CSEQUENCE as a type unless you really need a STRING. You can still use STRING variables and attributes to process the data internally, but the users of your method are free to choose the data type passed to the actual parameter.

As you can see in the example above, this is a fairly common problem. Even in the SALV framework you can find methods that require you to perform manual type conversion. But since it’s easily avoided, please give both the binary kittens and your fellow developer’s coronary arteries a thought and choose your parameter types wisely.