Que pensez-vous de cette nouvelle syntaxe if-then [fermé]

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 thensera 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 thenbloc serait comme le elsebloc d'un try-exceptbloc 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 thenbloc est limité au premier si tel elseest 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.

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é.

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.

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:

if (thisCondition or thatCondition)
{
  if (thisCondition)
     stuff();
  else
     otherstuff();

    stuff_that_applies_to_both();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

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:

if (thisCondition or thatCondition)
{
  stuff_that_applies_to_both();

  if (thisCondition)
     stuff();
  else
     otherstuff();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

Enfin, cette syntaxe permet une plus grande flexibilité avec plus de conditions: if (thisCondition ou thatCondition ou anotherCondition) {stuff_that_applies_to_all ();

  // Any combination of the three conditions using 
  // whichever logical syntax you'd like here
  if (thisCondition and anotherCondition)
     stuff();
  else if (thisCondition or thatCondition)
     stuff_number_2();
  else
     otherstuff();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

J'utilise if / else, mais j'aurais pu aussi facilement utiliser une instruction switch avec un indicateur:

Boolean conditionApplies = true;

switch (someConditionToCheck)
{
    case thisCondition:
      stuff();
      break;

    case thatCondition:
        otherStuff();
        break;

    default:
        stuff_that_doesnt_aply_sic_to_either();
        conditionApplies = false;
        break;
}

if (conditionApplies)
    stuff_that_applies_to_both();

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.

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 le Thenpar Doet le final Elsepar Otherwise.

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.

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 elsene se déclencherait pas. En le considérant sous cet angle, je dirais que l'on pourrait obtenir un résultat similaire via:

  faire
  {
    si (condition1)
      ... trucs pour condition1 seulement
    sinon si (condition2)
      ... trucs pour condition2 seulement
    autre
    {
      ... des trucs pour aucune des conditions
      Pause;
    }
    ... des trucs pour les deux conditions
  } while (0); // Point de continuation pour la pause

Une autre option peut dans certains cas être:

  if ((condition1 && (action1,1)) ||
       (condition2 && (action2,1)) ||
       (action_pour_neither, 0))
    action_for_either;

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).