3 ms·

What about this? var spawn = SKAction.runBlock self.spawnPipes

anon4 12y ago
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.
- lfuller 12y ago
  I'd argue the second is clearer in many cases. Readability trumps conciseness any day.
  - the_af 12y ago
    Really? In which cases would the previous example be clearer than return expression; What readability does the verbosity add?
  - MaulingMonkey 12y ago
    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.
- josephlord 12y ago
  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.
  - josephlord 12y ago
    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.
  - anon4 12y ago
    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.
sergejsb 12y ago
Are you sure this should work? I checked the grammar once more and it seems that closure-expression should always be enclosed in { ... }

anon4 12y ago

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.

lfuller 12y ago
I'd argue the second is clearer in many cases. Readability trumps conciseness any day.
- the_af 12y ago
  Really? In which cases would the previous example be clearer than return expression; What readability does the verbosity add?
- MaulingMonkey 12y ago
  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.
josephlord 12y ago
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.
- josephlord 12y ago
  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.
- anon4 12y ago
  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.

sergejsb 12y ago

Are you sure this should work? I checked the grammar once more and it seems that closure-expression should always be enclosed in { ... }