Open schmelto opened 2 years ago
I thought the 2 letter based comparison operators with equivalents might have been considered obsolete by now. Then it would have been covered by Avoid obsolete language elements. That is not the case though. Probably also because of range tables where you need to know these in any case.
The recommendation in the 7.56 keyword documentation just says you should pick either one but be consistent.
If you can choose from a range of comparison operators (= or EQ, > or GT, < or LT, >= or GE, <= or LE) we recommend that you pick a type of operator and stick to it within the context of a program. The variant with the characters =, <, and > is seen as more modern, but also overloads these characters. The comparison operators that consist of two letters are better matched to other comparison operators such as CO, CN, and so on, which have no alternative forms.
I personally would be in favor for using =
, >
, >=
, <
, <=
, <>
over EQ
, GT
, GE
, LT
, LE
, NE
in all cases as they are more in line with other languages and I don't mind mixing them with the more ABAP exclusive operators using the two letter style like CP
, CA
, NA
etc.
This did remind me of the remark in Don't chain assignments though regarding the multiple uses of =
depending on the context.
Thanks @fabianlupa that is a great explanation. I'm also in favor of using =
, >
, ... instead of using EQ
, GT
, ... due its (probably mostly for new developers) more in line with other languages as you also mentioned.
I'd leave the issue open though, maybe there's a consensus that the guide should include a chapter on this topic.
If in doubt, the variant with the characters =, <, and > is considered to be more up-to-date, however this also contributes to the overload of these characters.
Therefore i would see =,< and > as a recommendation except you need to mix it with CO, CN,..
Personally, I do not consider overloading an issue in a language where whitespace is significant. I vote for recommending the non-character-based operators whenever available.
I also vote for symbols instead of characters. In addition to what's mentioned already, characters are based on English language, so especially for non-native speakers it takes an extra millisecond to translate GE to "greater or equals" while >= is a universal symbol that doesn't require translation overhead.
Good point. Symbols like >
don't just transcend languages, though. They are even understood in different (albeit closely related) domains where most people have never heard of ABAP, namely mathematics.
Just because symbol operators are used in many other languages, I vote for them instead characters.
Hi there,
I have done a code review on legacy code today and definitely favor the symbols. Having the EQ, LT, GE in comparison to their counterparts was really throwing me off.
IF current_level LT new_level OR
current_level GE old_level.
vs.
IF current_level < new_level OR
current_level >= old_level.
The symbols (<, >=) are just much more readable imo. So yeah: I vote for <, >, = over LT, GE, EQ.
I also vote for symbols instead of characters. In addition to what's mentioned already, characters are based on English language, so especially for non-native speakers it takes an extra millisecond to translate GE to "greater or equals" while >= is a universal symbol that doesn't require translation overhead.
IMO this doesn't really make sense when every single ABAP keyword is based on English language. I consider relational operators like CN or NA to be much trickier, and they don't even have an alternative form.
My main concerns are:
Totally agree with @TheLazyHangman and the SAP docu. IMHO the consistent use is the essential point and should be enforced by the related styleguide, but in case of ABAP not what type is being used.
If the SAP would introduce '==' instead of '=' for comparison, I would prefer the symbol-based comparison.
Does CleanABAP recommend using
=
,>
,>=
,<
,>=
,<>
orEQ
,GT
,GE
,LT
,LE
,NE
when used as comparison operators? For reference see here.I did not find anything in the documentation.