Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comparison operators =, >, >=, <, >=, <> or EQ, GT, GE, LT, LE, NE #282

Open
schmelto opened this issue Aug 22, 2022 · 11 comments
Open

Comparison operators =, >, >=, <, >=, <> or EQ, GT, GE, LT, LE, NE #282

schmelto opened this issue Aug 22, 2022 · 11 comments

Comments

@schmelto
Copy link
Contributor

schmelto commented Aug 22, 2022

Does CleanABAP recommend using =, >, >=, <, >=, <> or EQ, GT, GE, LT, LE, NE when used as comparison operators?
For reference see here.

I did not find anything in the documentation.

@fabianlupa
Copy link
Contributor

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.

https://help.sap.com/doc/abapdocu_756_index_htm/7.56/en-US/index.htm?file=abenalternative_langu_guidl.htm

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.

@schmelto
Copy link
Contributor Author

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.

@schmelto schmelto changed the title Comparison operators =,<,>,<> or EQ,GT,LT,NE Comparison operators =, >, >=, <, >=, <> or EQ, GT, GE, LT, LE, NE Aug 23, 2022
@fabianlupa
Copy link
Contributor

I'd leave the issue open though, maybe there's a consensus that the guide should include a chapter on this topic.

@schmelto schmelto reopened this Aug 23, 2022
@mAltr
Copy link
Contributor

mAltr commented Nov 24, 2022

https://help.sap.com/doc/abapdocu_756_index_htm/7.56/en-US/index.htm?file=abenalternative_langu_guidl.htm

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

@N2oB6n-SAP
Copy link
Member

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.

@Jelena-P
Copy link

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.

@N2oB6n-SAP
Copy link
Member

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.

@krisk78
Copy link

krisk78 commented Feb 15, 2023

Just because symbol operators are used in many other languages, I vote for them instead characters.

@ebbmo
Copy link

ebbmo commented Aug 7, 2023

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.

@TheLazyHangman
Copy link

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:

  1. Functional context: the "=" symbol can be used both as relational and assignment operator, while "EQ" only works one way. So by using literals as relational operators and keeping the "=" for assignments only you are giving a unique context to each form. This is useful for example for restricting search results in your code.
  2. Length consistency: literals are all 2 characters long, while symbols can be 1 or 2, possibly resulting in bumpier SELECT or IF statements. This could easily be bypassed if the ABAP editor supported fonts with ligatures (such as Fira Code), but it doesn't seem to be the case.
  3. "Auto brackets" also works with the "<" character which is useful for field-symbols, but not for relational operators. One might argue that doing "a < b" and getting rid of the extra ">" takes the same amount of time as going directly with "a LT b", but I still find it less than optimal.

@mraht
Copy link

mraht commented Mar 13, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants