Swiftlint: Add rule for visually pleasing formatting of long guards

[Johennes]

New Issue Checklist

• [x] Updated SwiftLint to the latest version
• [x] I searched for existing GitHub issues

Rule Request

I'd like to suggest a rule for enforcing the style

    let a = ...,
    let b = ...,
    let c = ...
else {
    return ...
}

for guard statements where the (binding) conditions don't fit into a certain line length.

1. Why should this rule be added?

The proposed style clearly separates the condition from the body and keeps the indentation of the body consistent with the outer scope.

The currently allowed styles for long guards are

guard let a = ...,
    let b = ...,
    let c = ... else {
        return ...
}

guard let a = ...,
    let b = ...,
    let c = ... else {
    return ...
}

guard let a = ...,
      let b = ...,
      let c = ... else {
    return ...
}

The first one moves the else body in by two levels as compared to the outer scope which IMHO breaks the reading flow.

The second option has consistent indentation in the body but the condition lines following the first line have the same indentation which makes it hard to visually tell the end of the condition and the beginning of the body apart.

The last one, finally, uses an indentation for the condition lines that is not a multiple of the base indentation level in the rest of the code (here 2 spaces instead of 4) which IMHO is bad for readability as well.

1. Provide several examples of what _would_ and _wouldn't_ trigger violations.

Not ok:

See above, and

---------------------------------------| Line length limit
guard let a = ..., let b = ..., let c = ... else {
    return ...
}

Ok:

---------------------------------------| Line length limit
guard let a = ..., let b = ... else {
    return ...
}

---------------------------------------| Line length limit
guard
    let a = ...,
    let b = ...,
    let c = ...
else {
    return ...
}

See above.

1. Should the rule be configurable, if so what parameters should be configurable?

Yes, the severity level and the threshold line length.

1. Should the rule be opt-in or enabled by default? Why?

Opt-in because not everyone might like this style.

[Johennes]

We'd be willing to work on a PR for this but wanted to know if such a contribution would be welcome first.

[jpsim]

We'd be willing to work on a PR for this but wanted to know if such a contribution would be welcome first.

Certainly!

[ornithocoder]

Hi there! My team needs this rule and, if you don't mind, I'll give it a try.
I'll try to make it not conflict with existing rules, such as line_length and conditional_returns_on_newline

[Uncommon]

My favorite style is slightly different from the proposed one:

guard let a = ...,
      let b = ...,
      let c = ...
else {
    return ...
}

[samfranz]

Curious if there have been any advances in this? I know raywenderlich.com's swift style guide has it as this:

guard 
  let number1 = number1,
  let number2 = number2,
  let number3 = number3 
  else {
    fatalError("impossible")
}

[sjavora]

We'd be willing to work on a PR for this but wanted to know if such a contribution would be welcome first.

Yes please! I've come to format guards exactly this way. We also allow one more possiblity:

-----------------------------------------------------| Line length limit
guard let a = ..., let b = ... else { return ... }