Live data from Hacker News

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

llewellynfalco.blogspot.com

21–30 of 96 posts

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

#21
post #3

..but the greater than sign is still being used?

Where is the article using a >, aside from examples of what it is advocating against?

is there really a naming distinction between ‘>’ and ‘the ‘greater’ than sign? Interesting if so! I always assumed it was context dependent (i.e x < 10 could be said 10 is greater than x, so it’s still acting as a greater than sign - but I see why I’m probably wrong here). I was interested in seeing an arguement like another poster made, where notation be like x = [0,1] might be proposed.

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

#22
post #9

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 }

A somewhat stupid way to solve this issue (of what is likely poorly-designed API, given what you're trying to do here; optional Arrays are generally a code smell) is to abuse the nil coalescing operator:

  guard !(obj.someArray?.isEmpty ?? true)

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

#23
post #21

Earlier quoted context omitted.

Where is the article using a >, aside from examples of what it is advocating against?

is there really a naming distinction between ‘>’ and ‘ the ‘greater’ than sign? Interesting if so! I always assumed it was context dependent (i.e x < 10 could be said 10 is greater than x, so it’s still acting as a greater than sign - but I see why I’m probably wrong here). I was interested in seeing an arguement like another poster made, where notation be like x = [0,1] might be proposed.

If you read

  Pull the lever when x 
aloud, you must read it as "Pull the lever when x is less than zero." Thus, "" is "greater than", for that reason specifically.

Also, Unicode calls it U+003C LESS-THAN SIGN and U+003E GREATER-THAN SIGN.

At least, that's the terms that the article is using, and I think there's sufficient context to identify that, and go along w/ it.

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

#24

Earlier quoted context omitted.

In python you can just do 5 < x < 10

which is also the proper way you would read in any scientific paper, and very easy to read imho. 5 < x && x < 10 is the attempt to replicate this in other languages but falls a bit short

> 5 On the contrary, it's Python that added the shorthand, mathematical-looking notation because the longer "desugared" form wasn't great.

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

#25
post #21

Earlier quoted context omitted.

Where is the article using a >, aside from examples of what it is advocating against?

is there really a naming distinction between ‘>’ and ‘ the ‘greater’ than sign? Interesting if so! I always assumed it was context dependent (i.e x < 10 could be said 10 is greater than x, so it’s still acting as a greater than sign - but I see why I’m probably wrong here). I was interested in seeing an arguement like another poster made, where notation be like x = [0,1] might be proposed.

> is there really a distinction between ‘>’ and ‘The convention I've always seen is that `>` is "greater than" and ` 2` is "x is greater than 2" and `2 I don't know if the names are reversed in languages that are read right to left?

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

#26
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 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.

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

#27
post #7

I prefer to use the “5 I’ve arrived to the same general conclusion independently, which is reassuring.

Same with me, although I feel that putting the variable last is a form of Yoda programming. https://en.m.wikipedia.org/wiki/Yoda_conditions

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

#28
post #9

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 }

Why can that not be swapped to:

  guard let array = obj.someArray,
        0 

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

#30
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.

Post reply on HN