Don't use the greater-than sign in programming (2016)
llewellynfalco.blogspot.com
Don't use the greater-than sign in programming (2016)
1–10 of 96 posts
Re: Don't use the greater-than sign in programming (2016)
#2Ha, 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)"
Re: Don't use the greater-than sign in programming (2016)
#3..but the greater than sign is still being used?
Re: Don't use the greater-than sign in programming (2016)
#4Ha, 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)"
In Python we have if 2 <= x < 4.
Re: Don't use the greater-than sign in programming (2016)
#5Removing something doesn't necessarily make it more convenient to use. I'd find it bizarre if some language won't provide > using this logic.
Re: Don't use the greater-than sign in programming (2016)
#6as 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 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.
Re: Don't use the greater-than sign in programming (2016)
#7I prefer to use the “5 I’ve arrived to the same general conclusion independently, which is reassuring.
Re: Don't use the greater-than sign in programming (2016)
#8Re: Don't use the greater-than sign in programming (2016)
#9This 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
}Re: Don't use the greater-than sign in programming (2016)
#10This 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) .