from Hacker News

Don't use the greater-than sign in programming (2016)

by sheharyarn on 12/9/18, 4:15 AM with 94 comments

by danShumway on 12/9/18, 4:58 AM
I really think this is just bikeshedding over style.
If we were optimizing for readability and predictability, we'd standardize on the most commonly used format.
``if (x > 5 && x < 10)``
Putting a rule that variables should always be on the left hand side of a comparison also gives you only 2 ways to write any conditional, so it's just as good as getting rid of ``>``. It also has the advantage of being by far the most widespread way that people already write conditionals, so you don't need to hold a team meeting where you explain to a bunch of grumpy senior programmers why even though they think their coding style is easier to read it actually isn't.
But by far the best option is to not have a meeting at all and to not care about things like this. In the absence of real, tangible data that conditional styles are causing bugs, these kinds of debates are very often a pre-optimization, and pre-optimization should be avoided.
When I put the effort into tracking and ordering the root causes of the majority of bugs in my software (both in personal projects and in large corporate environments) I am often surprised at the results. Very rarely are they consistent with the causes I would have predicted.
That's why I call things like this bikeshedding. In a large organization, it is probably more productive for you to hold another meeting about encapsulation and code reviews than it is for you to start up a Slack discussion about what style people use on their conditionals.
by fl0wenol on 12/9/18, 4:42 AM
Qualification: Don't use the greater sign when doing range checks.
Counter-point: When checking if a variable is greater than a constant, using the less than is very confusing since we read left to right.
if(x > LIMIT) {
Read "If x exceeds LIMIT, then"
The opposite reads like "If the LIMIT is less than x", which sounds strange and emphasizes the wrong thing, implying LIMIT changed, not x.
by nostrebored on 12/9/18, 4:51 AM
This is incredibly poorly thought out. You don't only use conditionals while iterating. Even if you did, wanting to have a math like notation isn't necessarily reasonable. When reading a simple multi-part inequality like 5 < x < 10 I don't think "when 5 is less than x", I still think about it in terms of the variable. The benefit of arranging things in a simple inequality like above is the shorthand notation. You don't get that with:
5 < x && x < 10 vs. x > 5 && x < 10
by jamesbrennan on 12/9/18, 5:23 AM
Clojure has a nice way of achieving
```
  (5 < x && x < 10)
  This is a nice way of expressing "x is between 5 and 10" 
  because it is literally between 5 and 10. 
```
which is that the < function can take any number of arguments:
```
  (< 5 x 10)
```
https://clojuredocs.org/clojure.core/%3C
by fooker on 12/9/18, 4:40 AM
Ah, https://en.wikipedia.org/wiki/Yoda_conditions
by deathanatos on 12/9/18, 5:03 AM
I use this. I can read lines reading left to right with only </<= very quickly now, because of the visualization of a numberline in my head. Any other arrangement, and I have to slow down to my old, normal processing, and reason very carefully about the code, lest a subtle bug slip by.
For similar reasons, I find this notation helps me prevent errors, because they become visually detectable.
by lurquer on 12/9/18, 5:03 AM
I had to write a scripting language for a personal project. Since I could create whatever syntax I wanted, I used this:
'if x==4' was written as 'x[4]'
'if x>2 && x<4' was written as 'x(2,4)'
'if x>=2 && x<4' was written as 'x[2,4)'
Etc.
It was very easy to read and write... at least for me.
by nemo1618 on 12/9/18, 4:33 AM
Ha, I've been using this trick for a while, though I wouldn't go so far as to say "don't use the greater-than-sign." Honestly I just wish languages had a cleaner way to write "x is within this range," e.g. "if x in [2,4)"
by giomasce on 12/9/18, 11:21 AM
Another article along the lines of "I personally prefer to use a syntax in a certain case, therefore everybody should use the same syntax in every case, and really I do not understand why the language creators even allowed for the other syntax".
No, your are not smarter than everybody else. You just have different tastes, and you are not even covering all possible use cases (I would say that most people find "x > 0" more legible than "0 < x").
A lot of "Don't do" or "X considered harmful" article writers should really be a bit more careful before generalizing from "I like" to "everybody should" so quickly.
by johnday on 12/9/18, 4:42 AM
This just seems like an argument against putting the variable on the right hand side of the comparator.
You also only end up with two options, in the same way, and IMO (x > 5 && x < 10) is much more readable than (5 < x && x < 10) .
by nimbius on 12/9/18, 4:39 AM
as a CS major im sure this has academic value. as someone who is just learning python outside of a trade job as an engine mechanic, this idea makes me want to glass someone and im not sure why.
(5 < x && x < 10)
if we're talking about X, whats wrong with defining the parameters of its constraints in terms of X instead of dancing around the numbers? 5 < X makes it sound like im setting constraints on the number 5.
by fouc on 12/9/18, 5:09 AM
This article is too basic.
> (x < 10 && 5 < x) which is a stupid option because it implies 10 < 5
What? no it doesn't!
> (5 < x && x < 10)
It's already very obvious that one can take 5 < x < 10 and split it into 5 < x && x < 10 right off the bat. Loads of examples of that out there.
by dextersgenius on 12/9/18, 5:34 AM
http://4.bp.blogspot.com/-vglPHDBuUgI/VsniES7XnKI/AAAAAAAAD9...
The number line representation is incorrect. (5 < x && x < 10) represents x has possible values of 6,7,8,9 (assuming x is int), whereas the number line shows that 5 and 10 are inclusive, but that's not the case as per the provided example.
by benblu on 12/9/18, 5:59 AM
"Go ahead and find out which one, I'll wait" ... As if it required herculean effort.
"which is a stupid option because it implies 10 < 5" No it doesn't.
And I stopped reading.
by userbinator on 12/9/18, 5:20 AM
The bigger problem here is that if you say...
Let's say that I want to check that something is between 5 and 10.
...you did not specify explicitly whether the ends are inclusive/exclusive, and IMHO that (and the off-by-one errors it causes) is far more important.
Related: I've more than once had to ask someone whether "I will be away from 23 to 27" was inclusive or exclusive for the 27, because e.g. "meeting from 10 to 11" usually is exclusive at the upper end.
by shmerl on 12/9/18, 4:38 AM
Removing something doesn't necessarily make it more convenient to use. I'd find it bizarre if some language won't provide > using this logic.
by shurcooL on 12/9/18, 4:40 AM
I prefer to use the “5 < x && x < 10” style as well.
I’ve arrived to the same general conclusion independently, which is reassuring.
by brudgers on 12/9/18, 5:14 AM
Lately, I am enamored of Ruby
```
  x.between?(6,9)
```
or very explicitly
```
  x.between?(5.0.next_float, 10.0.prev_float)
```
by zapzupnz on 12/9/18, 4:41 AM
This all looks good to me until I'm unwrapping an optional and checking it's length in Swift, which normally looks like:
```
    guard let array = obj.someArray,
          array.count > 0 else {
        throw SomeError
    }
```
by karmakaze on 12/9/18, 5:49 AM
For normal scalars any are fine and I can see the number line merit of the post. Where I find much greater value is when dealing with points in time. Write x.isBefore(y) rather than y.isAfter(x) especially in compound contions.
by dang on 12/9/18, 8:26 AM
Discussed at the time: https://news.ycombinator.com/item?id=11148903
by SilverSlash on 12/9/18, 9:36 AM
Claiming you shouldn't use the greater than sign in conditionals because sometimes it's confusing is going too far.
Also in python you can just do `if 5 < x < 10` :)
by noobly on 12/9/18, 4:36 AM
..but the greater than sign is still being used?