I do exactly like you, except with only one tab inside the braces.

I usually go for enclosing the condition between the `guard` and the `else`:

    guard
      !argument.isEmpty,
      nums.count == agruments.count
    else {
      print("Usage: \(appName) ")
      exit(-1)
    }

I find it seperates condition from code nicely while still maintaining a nice level of indentation.

let isValidUsage = !argument.isEmpty &&
    nums.count == arguments.count
guard isValidUsage else {
    print("Usage: \(appName) ")
    exit(-1)
}

At the risk of being hanged from the nearest tree by the curly brace correct masses, this is they way my code would look:

guard
    !arguments.isEmpty,
    nums.count == arguments.count
else
{
    print("Usage: .... ")
    exit(-1)
}

Why must we be afraid to use white-space? The style that was used in the K&R C book all those years ago was intended to save paper.

I think you’re trying too hard to make it resemble if-else style statements. It’s supposed to be a 1-liner. if it leaks on more than 1 line then so be it

In ancient Persia, people were put to death for doing this:

    else
    {

(The Persians were a wise people. Mind you, they would have executed the Xcode team many times over for their crimes against tabs and indentation.)

I much prefer Patrick Perini’s approach:

    guard (
        !argument.isEmpty,
        nums.count == arguments.count
    ) else {
      print("Blah blah")
    }

I would write:

guard !argument.isEmpty, nums.count == arguments.count else 
{
    print("Usage: \(appName) ")
    exit(-1)
}

Can’t we get a .isNotEmpty method so as not to require the “!”

I’m not sure of the particular advantage of a guard in this case where there are no unwrapping of optionals. Why not just use an if statement?

Does anyone know the rationale for needing an “else” with guard in the first place? It feels forced — we would consider it very strange if a developer wanted to write

“if else { }”

Why not just “guard { }” ?

Can’t we just get rid of else? Can we? It adds nothing, in fact it slows me down because I keep forgetting to add it, and if it’s always necessary then it might as well not be there

I’m sure there’s a ‘frequently rejected proposals’ entry for this, but I’m digging in!

I agree with losing the else keyword. Also, it would be nice if there would be a way, if optionally/default desired. to somehow eliminate the “exit” statement in the else clause if with an some modification of the guard keyword which would provide an implicit exit. That way, Imo, the else clause (where the else keyword would also be gone) would be much easier to visually scan and type for many situations.

I think the behavior would be less completely obvious at a glance without the “else”, that tells your eyes right away that the attached clause is what executes if the conditions *aren’t* all true, so I can understand why it’s there; though I feel like that may only be necessary because “guard” itself fails to do that. Maybe they could have gone with, say, “unless” rather than “guard”, leaving out the “else” but otherwise being semantically identical.

This is probably heresy, but I like to seperate out my guard statements (note: Only a beginner swift programmer).

func TestFunc(check: Bool, name: String?) -> Bool {
guard check else { fatalError() }
guard name != nil else { return false }

….
return true
}