web-dev-qa-db-fra.com

Swift 2 - Cas d'utilisation de l'instruction break on if?

Le guide de Swift 2 mentionne que vous pouvez mettre fin au programme d'une instruction if. Personnellement, je n'ai jamais utilisé break avec if-statement.

Une instruction break termine l'exécution du programme d'une boucle, une instruction if, ou une instruction switch ... Quand une instruction break est suivie par le nom d'un libellé d'instruction, il termine l'exécution du programme de la boucle, si instruction, ou une instruction switch nommée par cette étiquette.

Dans quelle situation utiliserait-on une rupture dans une instruction if? Cette fonctionnalité de langue semble inutile.

TEST:
if (true) {
    break TEST
}
swiftif-statementbreakswift2
15
Boon

Utiliser break avec une déclaration if semble un peu artificiel, et je ne peux penser à un endroit où le style l'exigerait. Toutefois, il enregistre un niveau d'indentation supplémentaire lorsque vous ignorez la dernière partie d'une instruction if dans une clause if-else, ce qui peut être utile pour les boucles imbriquées en profondeur. 

Dans d'autres langues, un idiome populaire (et/ou controversé) consiste à utiliser des étiquettes pour gérer les erreurs dans des fonctions profondément imbriquées. Par exemple, on peut vouloir sortir d'une boucle en cas d'erreur, comme ceci:

func testBreak3() {
    // doesn't compile!!!
    let a = false, b = true, x = 10, y = 20, err = true
    if !a {
        if b && x > 0 {
            if y < 100 {
                if err {
                    break handleError
                }
                // some statements
            } else {
                // other stuff
            }

        }
    }
    return  // avoid error handling

    handleError:
    print("error")
    // handle the error
}

Mais dans Swift (j'utilise 2.0 comme référence), les étiquettes sont différentes de celles des autres langues. l'exemple ci-dessus ne se compile pas pour deux raisons: L'étiquette n'est pas encore déclarée lorsqu'elle est utilisée et elle doit être directement associée à une instruction do, while, if ou case. En outre, une interruption dans une instruction if ou do nécessite que cette instruction soit étiquetée. Nous pouvons résoudre ce problème comme suit, bien que les modifications rendent la solution moins attrayante en raison d'un suivi supplémentaire via la variable errorFlagged, ce qui rend le refactoring plus attrayant:

func testBreak() {
    let a = false, b = true, x = 10, y = 20, err = true
    var errorFlagged = false
    nestedIf: if !a {
        if b && x > 0 {
            if y < 100 {
                if err {
                    errorFlagged = true
                    break nestedIf
                }
                // some statements
            } else {
                // other stuff
            }
        }
    }

    // skip handling if no error flagged.
    if errorFlagged {
        print("error")
        // handle error
    }
}
10
rholmes

Par exemple, si vous souhaitez décrire un nombre (avec des chaînes) en faisant référence à des ensembles de nombres (nombres pairs/rationnels/négatifs), votre code pourrait ressembler à ceci:

if condition1 {
    // code
    if condition2 {
        // code
        if condition3 {
            // code
            if condition4 {
                //code
            }
        }
    }
}

Vous pouvez obtenir la même logique, mais sans les if imbriqués, en la restructurant (à l'aide de guard):

OuterIf: if condition1 {
    // code

    guard condition2 else { break OuterIf }
    // code

    guard condition3 else { break OuterIf }
    // code

    guard condition4 else { break OuterIf }
    // code
}

// reads even better when breaking out of "do"
scope: do {
    guard condition1 else { break scope }
    // code

    guard condition2 else { break scope }
    // code

    guard condition3 else { break scope }
    // code

    guard condition4 else { break scope }
    // code

}

Vous pourriez penser que ceci peut également être réalisé avec switch et fallthrough, mais cela ne fonctionne pas avec les cas "normaux" car il vérifie toutes les conditions et si une condition est remplie, toutes les conditions suivantes ne sont même pas évaluées.

Donc, la fallthough doit être appelée conditionnellement.

Cela fonctionne mais je ne suis pas très lisible, sans parler de sa "beauté":

let x = 4
switch x {
case _ where condition1:
    // code
    if condition2 { fallthrough }
case _ where false:
    // code
    if condition3 { fallthrough }
case _ where false:
    // code
    if condition4 { fallthrough }
case _ where false:
    // code
    break
default: break
}
13
Qbyte

Je sais que c’est un sujet ancien, mais j’ai utilisé tout à l’heure le break et c’était nécessaire. Donc, mon exemple J'ai un tableau d'objets. Lorsque l'utilisateur appuie sur une cellule, i.parameter devient True pour l'objet de cette cellule . J'ai besoin de savoir quand tous les objets du tableau ont i.parameter = True, c'est la condition pour arrêter le jeu. .

func forTimer(){
   for i in array {
   if i.parameter = false
   break
 }
}
timer = Timer.scheduledTimer(timeInterval: 0.001, target: self, selector: #selector(forTimer), userInfo: nil, repeats: true)

Même si un i.parameter = false, je n'ai pas besoin de vérifier le reste du tableau. Cette fonction est appelée toutes les millisecondes, je n’aurai donc pas besoin de vérifier le tableau entier toutes les millisecondes. 

0
Anna Orlova