Je pensais juste à quelque chose qui serait vraiment cool d'avoir dans mes commandes if-elif-else.
if condition:
stuff()
elif condition:
otherstuff()
then:
stuff_that_applies_to_both()
else:
stuff_that_doesnt_aply_to_either()
Donc, fondamentalement, a then
sera exécuté lorsque l'une des conditions est exécutée SAUF la condition else. Pensez-vous que cela soit utile? C'est similaire au try-except-else de python.
Je pense que certains d'entre vous choisissent une mise en œuvre très préliminaire. Le then
bloc serait comme le else
bloc d'un try-except
bloc en python. La vraie raison pour laquelle je suggère cela est pour des situations comme celle-ci.
m = {}
if condition == '1':
m['condition'] = condition
elif condition2 == '3':
m['condition2'] = condition2
elif condition3 == 'False':
m['condition3'] = True
then:
run_test_that_relies_on_one_of_the_conditions_being_true()
return m
Le then
bloc est limité au premier si tel else
est le cas. L'imbrication fonctionne donc très bien. Et si vous devez exécuter une méthode avant les instructions if, cela n'a vraiment rien à voir avec ce cas d'utilisation.
finally
en Java?then
c'est un peu déroutant. Ilthen
est généralement implicite de se produire après unif
. Je veux dire, vous dites,if condition, then stuff()
mais continuez à direthen stuff that applies to both
Réponses:
Je pense que ça a l'air horrible. Si vous souhaitez que le code s'exécute après diverses conditions, alors (a) revérifiez ces conditions ou (b) définissez une variable sur l'état de réussite indiqué.
la source
Généralement, vous pouvez déjà le faire avec un commutateur / boîtier et un commutateur / boîtier offre un contrôle plus fin de ce que vous proposez.
Il ne lit pas non plus correctement de manière logique. Si A, sinon B, alors C. N'implique pas à quelqu'un que C sera exécuté si A ou B est évalué comme vrai.
la source
Intéressant, mais il me semble (certes quelque peu réglé à mes yeux) une invitation aux problèmes de lisibilité, de logique et de syntaxe.
Edit:
Votre if-elif est très simple - et s'il y avait 10 elifs? 20? Toutes les conditions devraient-elles être remplies? Quelles sont les chances pour ça?Votre if-elif est très simple - et s'il y avait 10 elifs? 20? Cela ne rendrait-il pas cela assez illisible?
En outre, peut facilement être atteint par une méthodologie éprouvée:
Que se passe-t-il si "stuff_that_applies_to_both" doit se produire avant les étapes individuelles? Votre code ne gère pas ce cas:
Enfin, cette syntaxe permet une plus grande flexibilité avec plus de conditions: if (thisCondition ou thatCondition ou anotherCondition) {stuff_that_applies_to_all ();
J'utilise if / else, mais j'aurais pu aussi facilement utiliser une instruction switch avec un indicateur:
Notez que je n'avais pas réellement besoin de l'indicateur conditionApplies - j'aurais pu ajouter la fonction "stuff_that_applies_to_both ()" aux deux conditions non par défaut - je viens de le faire pour que cela ressemble plus à la syntaxe définie ci-dessus, bien que le "alors" plutôt que le "else".
Par conséquent, il me semble que c'est une syntaxe très spécialisée, où une syntaxe plus générale remplit le projet de loi et plus encore.
+1 pour avoir pensé à une fonctionnalité possible (continuez à faire ça!), Mais je ne voterais pas pour l'implémenter.
source
what if there were 10 elifs? 20? Would all conditions need to be true?
Ce n'est pas possible. seul 1 elif peut être vrai car il cesse d'évaluer plus.Cela ne me dérangerait pas d'utiliser moi-même quelque chose comme ça aujourd'hui. Mais, pour être sûr, je l'utiliserais aussi souvent que j'utilise répéter jusqu'à.
Le code aurait au moins une meilleure apparence sans l'imbrication superflue. Bien que je préfère
Else If
àelif
. Je remplacerais leThen
parDo
et le finalElse
parOtherwise
.source
Cela semble être une bonne idée. Cependant, le seul problème que j'imagine est que vous êtes plus sujet aux bugs. Comme écrire un if / else if et appeler blah () dans then. Ecrire un extra supplémentaire si cela ne veut pas bla, supprimer bla à partir de là et l'ajouter à vos ifs / elseifs. Ensuite, lorsque vous ou un autre programmeur ajoutez une autre instruction, vous pouvez vous attendre à ce que blah soit appelé, mais pas.
Ou vous pouvez avoir plusieurs ifs, écrire un bla et oublier tous les ifs mais un seul l'exige, ce qui casserait quelque chose. Il y a aussi des chances que si vous en avez besoin pour suivre chaque si vous le mettez sous le bloc if. Définir éventuellement un bool dans else (NoUpdate = true) et simplement écrire un if (! NoUpdate) {} directement sous lequel est plus clair et peut être défini par un if
Je dis juste qu'il semble plus sujet aux bugs, pas que je n'aime pas l'idée. Cela ne me dérangerait pas de le voir dans une langue mais je ne peux pas imaginer n'importe quelle situation où je l'utiliserais si ma langue le supporte.
la source
Possibly setting a bool in else (NoUpdate=true) and just write a if(!NoUpdate) {} directly under which is clearer and can be set by an if
C'est exactement ce que cela est censé empêcher. C'est tout l'intérêt d'une déclaration elif. Elif n'est pas non plus nécessaire, il peut être vérifié avec des instructions if, mais cela se complique.Je trouve votre syntaxe déroutante, mais je vois une certaine valeur dans le concept. Sur le plan conceptuel, lorsque j'ai examiné le problème, ce que je me suis retrouvé à vouloir, c'est un "non exécuté", qui, fondamentalement, exécuterait les choses dans les cas où le dernier
else
ne se déclencherait pas. En le considérant sous cet angle, je dirais que l'on pourrait obtenir un résultat similaire via:Une autre option peut dans certains cas être:
Un peu désagréable, mais dans certains cas, il peut ne pas y avoir de bon moyen d'exprimer la séquence d'événements souhaitée autre que la duplication de code ou l'utilisation
goto
(ce qui pourrait ne pas être si mauvais, sauf pour le dessin animé que quelqu'un pourrait insérer ici).la source