I am wondering what the most idiomatic text abbreviations for comparison operators are. I need to build a custom enum with them, so I cannot use their symbols. To me personally, these seem idiomatic:==  EQ!=  NEQ<   LT<=  LTE>   GT>=  GTEHowever, some other languages seem to use 2-letter words: EQ, NE, GT, GE, LT, LE.But I have also seen these been used (for example in querydsl): EQ, NE, GT, GOE, LT, LOE.And C# seems to avoid the problem by just writing them out: Equal, NotEqual, LessThan, LessThanOrEqual, GreaterThan, GreaterThanOrEqual.It seems insignificant, but I need to decide for one variant nontheless. And I might as well try to choose the right one.(Also sorry if software engineering isn't the right community for this, but I didn't seem to find a better place to discuss naming conventions)
What are the most idiomatic abbreviations for comparison operators
comparison;operators;shortcuts
As a Rule of Thumb, the less a developer has to guess to understand something, the better.One of the main reasons Enumerators where created is to avoid those pesky magic numbers and magic strings that nobody really could remember what they did two weeks later. They can also put a constraint on what values you can pass to a given function or method if the language supports strong typing, which also helps to avoid programming mistakes. With that in mind, the more explicative the Enumerators are, the better. Just check this example:switch(Comparer){    case Operator.Equals:        DoSomething();        break;    case Operator.GreaterThan:        DoSomethingElse();        break;}Compare this with the alternative, more compact abbreviations:switch(Comparer){    case Operator.EQ:        DoSomething();        break;    case Operator.GT:        DoSomethingElse();        break;}The difference is subtle, but the first example is way more readable. When you have a decent IDE with a good autocomplete by your side, you end up not even noticing the extra characters while developing, but you will notice then when debugging and you'll be glad they are there. So, unless you have some really good reason to golf your code, make your enumerators clear and easy to understand. Your Future You will thank you later.