Flappy Bird in Swift

Re:Flappy Bird in Swift by anon4 on Tuesday June 03, 2014 @05:39PM (#7842895)

Heh. Reminds me of when I correct people for

  if var == true {...}

or (and I have actually seen this)

  if (<expression> == true) {
      return true;
  } else {
      return false;
  }

I sometimes think that simply giving those 5 lines to a person and observing if they make a face like you've handed them a bucket full of day-old fish is a better test for programming aptitude than anything.

[ Parent | on HN ]

Re:Flappy Bird in Swift by josephlord on Tuesday June 03, 2014 @09:50PM (#7843629)

  if var == true {...}

In some languages var might be truthy but not equal to true. The falsy values may be more of a problem at times.

However in the strongly typed swift I don't think it will be a problem as I suspect (but haven't read/tested enough yet to confirm) that only false and nil will be falsy and that comparison with true will throw errors if var isn't of bool type.

[ Parent | on HN ]

Re:Flappy Bird in Swift by josephlord on Wednesday June 04, 2014 @08:01AM (#7845050)

Just tried it. In Swift:

  3 == true    // Give an error (operator overload doesn't cover this)
  true == 3    // Returns false
  nil == false // Returns false

You can't use nil or integers directly in an if statement without a function to return a logic value.

[ Parent | on HN ]

Re:Flappy Bird in Swift by anon4 on Saturday June 07, 2014 @05:07PM (#7863105)

Yes, such languages exist, and even in C++ if (x == true) is different from if (x), given that x is any number kind other than boolean, but my comment was only for the case when the two would be equivalent.

[ Parent | on HN ]

Re:Flappy Bird in Swift by lfuller on Tuesday June 03, 2014 @05:50PM (#7842945)

I'd argue the second is clearer in many cases. Readability trumps conciseness any day.

[ Parent | on HN ]

Re:Flappy Bird in Swift by MaulingMonkey on Wednesday June 04, 2014 @01:12AM (#7844143)

I agree that readability trumps shortness of code. I want not for APL nor code run through a javascript minifier.

But the branch and explicit boolean comparison are additional structural complexity (not just "verbosity") and invariably harms readability to me. Care give a poster child example for where it helps readability? Unless it's unclear <expression> results in a boolean - a problem better solved through better naming - code like this forces me to perform the equivalent simplification in my head to understand and reason about the code, a process fraught with error and distraction from my actual task.

[ Parent | on HN ]

Re:Flappy Bird in Swift by the_af on Tuesday June 03, 2014 @08:19PM (#7843437)

Really? In which cases would the previous example be clearer than

    return expression;

What readability does the verbosity add?

[ Parent | on HN ]