What are the most idiomatic abbreviations for comparison operators [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

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
>=  GTE

However, 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)

Answer 1

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.

Answer 2

You seem to be conflating tokens in a grammer and identifiers in a program.

As your usage is identifiers in a program, I'd go with whatever your style guide suggest for naming things (or LessThan if you have no style guide), e.g.

Expression<Boolean> LessThan(Expression<T> lhs, Expression<T> rhs)
{
    return new ComparisonExpression(Comparisons.LessThan, lhs, rhs);
}