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)

  • 2
    i'd just right them out, dont want to spend time trying to remember whether LE was < or <= 6 months down the line
    – jk.
    Jun 28, 2017 at 12:11
  • 3
    @jk. I double your words. When dealing with unusual code, the less the developer has to guess to find out what something does, the better. Personally, I really dislike those 2 or 3 letters abbreviations - My first thought reading one of those rarely is what they actually mean. C# ends up being very verbose sometimes, but I can't deny that the code can end up extremely clear if you don't do anything "clever".
    – T. Sar
    Jun 28, 2017 at 12:23
  • @T.Sar I'd say that it is not C# that is verbose, but MS! However with decent inteliisense and tab completion it's not much of an issue.
    – Peter M
    Jun 28, 2017 at 12:47
  • 1
  • 2
    When I first read that question, I thought it was not a good question. Then I read the accepted answer, which turned my mind, because it is definitely the one and only correct answer.
    – Doc Brown
    Jun 28, 2017 at 18:57

2 Answers 2


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:

    case Operator.Equals:
    case Operator.GreaterThan:

Compare this with the alternative, more compact abbreviations:

    case Operator.EQ:
    case Operator.GT:

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.

  • thanks, I went with EQUAL, GREATER_THAN etc. (upper snake case because of java style conventions)
    – Felk
    Jun 28, 2017 at 15:53

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);

Not the answer you're looking for? Browse other questions tagged or ask your own question.