Golden Path about swift-style-guide HOT 17 CLOSED

That said, I understand that a style guide shouldn't be a straight jacket. While I may elide the let from the example, we don't have to necessarily rule on it.

👍

from swift-style-guide.

I would agree here but what about optional binding? Sometimes there are a big mess of if let cases stacked up with the "happy" code way down in all the curly braces.

I suppose we could replace that with many checks for nil, but that seems against the Swift way.

from swift-style-guide.

Checking for nil is definitely going against swift in my opinion. Then when you're done you're left to use forced unwrapping which feels even worse. 

—
Chris

On Tue, Dec 2, 2014 at 6:54 PM, Greg Heo [email protected] wrote:

I would agree here but what about optional binding? Sometimes there are a big mess of if let cases stacked up with the "happy" code way down in all the curly braces.

I suppose we could replace that with many checks for nil, but that seems against the Swift way.

Reply to this email directly or view it on GitHub:
#63 (comment)

from swift-style-guide.

I think the scenario we should discourage is nesting a big mess of if let statements.

E.g.

if let object1= optional1 {
  if let object2 = optional2 {
     if let object3 = optional3 {
        // important code is nested deep inside here...
     }
   }
} else {
  // handle missing values
}

Seems bad.

Instead, I propose this is cleaner:

if optional1 == nil || optional2 == nil || optional3 == nil {
  // handle missing values
  return;
}

let object1 = optional1!
let object2 = optional2!
let object3 = optional3!

// important code is aligned with the left

from swift-style-guide.

Hm - I worry about that second approach - it seems more error-prone than nested if lets. What if someone adds a let object4 = optional4! but forgets to add it in the if statement? Also I think ! should be avoided as much as possible, we shouldn't be encouraging it...

from swift-style-guide.

If they added another let object4 = optional4! without adding it to the if statement, you would hope that the app would crash quickly, but I can see how this may persist as a silent bug if the input is present most of the time...

Maybe there isn't a good solution to this issue, and it should be addressed on a case by case basis?

For example, start by questioning, "Why do I have four optionals here...?"

Unless others have a better suggestion on how to address this, perhaps this should simply be closed...?

from swift-style-guide.

I'd worry a little bit too, especially if there might be "in between" work to do, e.g.:

if let object1= optional1 {
  // do something with object1 here
  if let object2 = optional2 {
     if let object3 = optional3 {
       // do something with objects 1,2,3
     }
   }

I guess you could split that up into two if blocks, one for just object1 and another for all of 1,2,3.

I feel like Swift is going to get multiple bindings some day, like this:

if let object1 = optional1 && object2 = optional2 {
}

In that case, I'd have to argue against the usual golden path and say it's an established Swift idiom to have the "happy path" inside the conditional.

from swift-style-guide.

Closing this issue as the group seems to agree that the Golden Path has undesirable consequences in Swift.

As @gregheo mentions, hopefully Swift will have multiple let bindings included one day. When such day comes, perhaps such can be recommended to be added to the guide.

:]

from swift-style-guide.

With the introduction of guard in Swift 2.0, I think we should consider adding the Golden Path to our Swift guide.

I think many agree this is a good idea in Swift now and are already following it in their writing.

from swift-style-guide.

Also, multiple guard / let bindings are now allowed by putting a comma between them. :]

from swift-style-guide.

I agree. Example from above in Swift 2.0 should look more like this:

guard let optional1 = optional1, let optional2 = optional2, let optional3 = optional3 else {
    // handle missing values
    return;
}

// important code is aligned with the left

from swift-style-guide.

Approved. I will be adding a section about golden path and guard in the style guide. @lukewar I like your example but ... that semicolon ... 😆

from swift-style-guide.

lol, jumping between Swift and ObjC is harder than one would think :P

from swift-style-guide.

How about dropping the let duplicates from that example? You guys think they add clarity?

guard let optional1 = optional1, optional2 = optional2, optional3 = optional3....

from swift-style-guide.

I'm against dropping the let duplicates, or at least, making a hard rule there shouldn't be any duplicates.

Reasoning:

(1) If you include a where clause, you must specify let again. For example, this is a problem:

Not Allowed:

func doSomethingWithOptionalNumber(number1: Int?, number2: Int?) {

  guard let number1 = number1 where number1 > number2,
    number2 = number2 else {   //  COMPILER ERROR
      print("Number criteria not met!")
      return
  }

  // ... here be magic...
}

(2) If you have a mix of var and let, it can be unclear what your intentions are if you omit the let/var specifier:

Potentially Unclear:

guard let number1 = number1,
  var number2 = number2,
  number3 = number3 else { // Did you really mean for this to be `var` or actually `let`?
    return
}

I'd propose:

• There should always be a let/ var, even if redundant.
• Or, the decision should be left up to the tutorial author, depending on context.

from swift-style-guide.

Use of var is deprecated (and will be an error in Swift 3) so that argument is out. Also, if you order correctly you can omit the let with where.

func doSomethingWithOptionalNumber(number1: Int?, number2: Int?) {

  guard let number1 = number1, number2 = number2 where number1 > number2
    else {   //  COMPILER ERROR
      print("Number criteria not met!")
      return
  }

  // ... here be magic...
}

That said, I understand that a style guide shouldn't be a straight jacket. While I may elide the let from the example, we don't have to necessarily rule on it.

from swift-style-guide.

@rayfix Admittedly, these were contrived examples. 😉

However, you definitely won't always be able to reorder to get rid of the necessity for the second let.

Regarding,

Use of var is deprecated

You can only have let variables now?! That's definitely quite a shift to functional programming in Swift!

😱 😱 🙀

Jokes aside though, only var method parameters are deprecated. You can definitely have var in a guard statement. Here's an example:

func addDefaultHeadersTo(headers: [String: String]?) -> [String: String] {

  let defaultHeaders = ["AppVersion": "1.0.42",
                        "Who's Awesome?": "Ray Fix"]

  guard var headers = headers else {
    return defaultHeaders
  }

  for (key, value) in defaultHeaders {
    headers[key] = value
  }

  return headers
}

from swift-style-guide.