Live data from Hacker News

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

llewellynfalco.blogspot.com

61–70 of 96 posts

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

#61

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 widesp…

But by far the best option is to not have a meeting at all and to not care about things like this. Indeed. This article reads like someone who doesn't understand inequalities, and proposes a quite possibly hazardous shortcut to it instead. To not understand such basic maths is baffling (this is primary-school stuff), and I wonder at the state of maths education these days to see adults struggling with these concepts.…

> This article reads like someone who doesn't understand inequalities, and proposes a quite possibly hazardous shortcut to it instead.

This is how I usually write inequalities. Have you considered that possibly the author and I understand how they work and would like a consistent way of formatting them to save time while reading them?

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

#62

Earlier quoted context omitted.

Swift has it. I'm sure a few languages must have it. if (2...4).contains(x)

This doesn't work for me: $ swift Welcome to Apple Swift version 4.2.1 (swiftlang-1000.11.42 clang-1000.11.45.1). Type :help for assistance. 1> let x = 3 x: Int = 3 2> if x in 2...4 {} error: repl.swift:2:6: error: expected '{' after 'if' condition if x in 2...4 {} ^ Are you sure you didn't mean to use if case? if case 2...4 = x

Yeah, I was wrong. I updated my comment. I think I just meant to check if a range contains a value, as I changed it to.

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

#63

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.

Because all of the author's number line representations are consistent, I think you can consider them placing an implicit "open circle" on the bounds of all those ranges on the number line.

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

#64

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 widesp…

I agree that this is trivial. But I also write conditionals the way the author suggests. Mostly because that is the way you'd write it if this was math. You'd say 'For x between 5 and 10' and write '5 < x < 10'.

To be clear, my point is not that a math-centric style is bad. My point is that 95% of the time it doesn't matter.

If you were working with me on a project, unless I had solid evidence that conditional styles were causing bugs, your style might warrant one curious comment on a single code review, but nothing else.

If it became obvious that it was causing bugs, we'd standardize on whatever the majority of people in the office already used, even if that was:

``if(10 > x && 5 < x)``

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

#65
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

It could be changed to that, but what am I really asking? "Is zero lower than the length of my array" is a bizarre way to word the question, as opposed to "is the length of my array greater than zero".

I believe in self-documenting and obvious code, and I think if statements should read as much like a human sentence as possible.

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

#66
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 }

`array.count < 1` still sounds reasonable though.

Only if I _want_ the array to be empty, otherwise I have to put an ! in front of the that — which in Swift also needs brackets — which is just adding noise to the signal, really, which really defeats the purpose of avoiding the greater than symbol here.

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

#67

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 widesp…

The article was about programming style. You write about team meetings. There is a disconnect.

Unless you plan to only work on personal projects by yourself, any kind standardization in your codebase will always require some kind of team meeting.

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

#68

Earlier quoted context omitted.

This doesn't work for me: $ swift Welcome to Apple Swift version 4.2.1 (swiftlang-1000.11.42 clang-1000.11.45.1). Type :help for assistance. 1> let x = 3 x: Int = 3 2> if x in 2...4 {} error: repl.swift:2:6: error: expected '{' after 'if' condition if x in 2...4 {} ^ Are you sure you didn't mean to use if case? if case 2...4 = x

Yeah, I was wrong. I updated my comment. I think I just meant to check if a range contains a value, as I changed it to.

You can use ~= if you're looking for a succinct way to do an operation like this:

  if 2...4 ~= x

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

#69
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)

Well sure, except if the array is optional (and I agree it's code smell, but that's what you get when you use other peoples' libraries, I guess) that statement doesn't unwrap the array for me to use; I'll either need to do it manually on a second line (waste of effort) or every time I try accessing that variable. If I access it a lot, this is inefficient duplication.

Plus, I don't like abusing the nil coalescing operator. Once you're abusing anything, you're adding signal to noise and making the intent of a statement less clear than necessarily, I feel.

+1 for isEmpty, though. According to the docs, count iterates over collections that don't conform to RandomAccessCollection, so best to avoid unnecessary overhead by adopting good practice! Thanks for that.

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

#70

Earlier quoted context omitted.

Swift has it. I'm sure a few languages must have it. if (2...4).contains(x)

Does that work for floats?

Yes, if you use the pattern matching operator I suggested to the original comment's author:

  $ swift
  Welcome to Apple Swift version 4.2.1 (swiftlang-1000.11.42 clang-1000.11.45.1). Type :help for assistance.
    1> let x = 3
  x: Int = 3
    2> let y = 3.0
  y: Double = 3
    3> 2...4 ~= x
  $R0: Bool = true
    4> 2...4 ~= y
  $R1: Bool = true
Post reply on HN