$-variables will be deleted even though they are used

[LechnerClemens]

Sadly some legacy code of ours uses variables with the "$" prefix. ABAP-Cleaner deletes the definition no matter what.

Here a quick example.
Before:

form my_test_form.

  data $my_var type string.
  data l_is_hello_world_active type abap_bool.

  $my_var = 'Hello world'.

  if $my_var = 'Hello world'.
    l_is_hello_world_active = abap_true.
  endif.

endform.

After:

form my_test_form.
  " TODO: variable is assigned but never used (ABAP cleaner)
  data l_is_hello_world_active type abap_bool.

  $my_var = 'Hello world'.

  if $my_var = 'Hello world'.
    l_is_hello_world_active = abap_true.
  endif.

endform.

Thank you in advance!

[ConjuringCoffee]

This seems to be true for any special character. I've tried it with % or &.

[LechnerClemens]

Is this something that can or will be fixed?

[jmgrassau]

Hi Clemens,

wow, I've never seen such a variable. Which ABAP release are we talking about here? We'd have to find out what exactly the naming conventions were at the time.

Kind regards,
Jörg-Michael

[ConjuringCoffee]

Programs are supporting these variable names even on S/4 release 7.57. 😉

[jmgrassau]

Hi ConjuringCoffee,

you're right, I just tried that … ABAP really goes to great lengths to be downward compatible! However, I didn't find anything on this supported legacy naming in the documentation yet, will ask our documentation expert about it.

Kind regards,
Jörg-Michael

[LechnerClemens]

We are currently on 757. I don´t know where this originated from.
But we are not talking small numbers here, in some old reports 75% of the variables are named like that. Maybe renaming would also be something to consider....

[jmgrassau]

Hi Clemens,

here's the result of some trial and error:

REPORT zany_report.

" accepted in non-OO context:
DATA: $a, a$.
DATA: %a, a%.
DATA: *a, a*.
DATA: ?a, a?.

DATA: <a. " but NOT a>
DATA: &a. " but NOT a&
DATA: !a. " but NOT a! This declares the variable a (to be used with or without the '!')

DATA: a#. " but NOT #a
DATA: a>. " but NOT >a or a>a

" not possible in Unicode programs (warning)
DATA: -a, a-.

" not possible in Unicode programs (error)
" DATA: a<.
" DATA: a&.
" DATA: a!.

" DATA: #a.
" DATA: >a, a>a.

" DATA: a;.
" DATA: a=.
" DATA: a}.
" DATA: a|.

" DATA: §a, a§.
" DATA: €a, a€.
" DATA: °a, a°.
" DATA: ^a, a^.
" DATA: ~a, a~.
" DATA: [a, [a.
" DATA: ]a, ]a.
" DATA: {a, a{.
" DATA: @a, a@.

Usually, if a* is possible (* symbolizing any special character), a*a is also possible and vice versa, with the exception of the special character >, where a> is possible, but not a>a.

Do you have the impression that my 'accepted in non-OO context' section covers the special characters that you see in those 75%, or do you even have variable names that are not allowed in unicode programs?

Kind regards,
Jörg-Michael

[jelliottp]

I have seen quite a bit of standard code with % prefixes also, so in some older cases it has made it into our code as well. This would be a good addition to the rules.

[LechnerClemens]

The only version which i have ever seen is $a with variables - *a is also used but only for table-statements.

[jmgrassau]

Hi,

the more you experiment, the more shocking it gets:

  " accepted in non-OO context:
  DATA: $, %, ?.

  " marked in red by ADT, but no syntax error:
  DATA: * TYPE i, < TYPE i, & TYPE i.

  < = 1.
   * = 2.
  & = < + *.
  IF < + * * < < & * < + *.
    < = & + *.
  ENDIF.

  WRITE: / <, *, &.

or, as a screenshot:

Try to guess the result of the WRITE statement!

With the help of the program DEMO_CHARACTERS_IN_ABAP_NAMES, I now figured out the following regarding characters used in data objects / data types / procedure names / procedure parameters in Unicode programs:

• A-Z _ a-z: okay everywhere
• 0-9: okay everywhere, except as first char in OO context (error)
• %: okay at any position outside OO, okay as %_… in OO context, otherwise error
• $ * ?: okay at any position outside OO, otherwise error
• & <: okay as first char outside OO, otherwise error
• #: okay as non-first char outside OO, otherwise error
• >: okay as last char outside OO, otherwise error
• -: okay at any position in procedure name outside OO; warning at any position in data object or procedure parameter outside OO; otherwise error
• ! " ' ( ) + , . / : ; = @ [ \ ] ^ ` { | } ~: error everywhere (note however that ! is used as an escape character for identifiers)

I shall try to adjust ABAP cleaner accordingly!

Kind regards,
Jörg-Michael

[jmgrassau]

Hi Clemens,

thank you very much for reporting this! This should be fixed with the next release, meaning that ABAP cleaner should then correctly recognize all of the following variable names in a non-object-oriented context:

FORM any_form.
  DATA: %a, %_a, a%b, a%, %. " %_a is even possible in an OO context
  DATA: $a, $_a, a$b, a$, $.
  DATA: ?a, ?_a, a?b, a?, ?.
  DATA: *a, *_a, a*b, a*.    " * alone would be marked in red

  DATA: &a, &_a. " & is only possible as the first char
  DATA: <a, <_a. " < is only possible as the first char
  DATA: a#b, a#. " # is only possible as a non-first char
  DATA: a>.      " > is only possible as the last char and only if the first char is NOT <
ENDFORM.

The forms with - such as -a, -_a, a-b, a- (which produce a warning) will NOT be recognized.

Kind regards,
Jörg-Michael

[jmgrassau]

Hi Clemens,

thanks a lot for reporting this, I really wonder why it came up only now! – Anyway, this should now be fixed with version 1.11.2, which was just released!

Kind regards,
Jörg-Michael

[LechnerClemens]

Hi Jörg-Michael,

no, thank you so much! ABAP-Cleaner is awesome and it helps us a lot with making legacy code a bit more easy on the eyes! That was an important fix for us - thanks for implementing this so fast!

Kind regards,
Clemens

[jmgrassau]

Hi Clemens,

that's great to hear, very happy that I could help!

Kind regards,
Jörg-Michael