Was halten Sie von dieser neuen Wenn-Dann-Syntax [geschlossen]

Ich dachte nur an etwas, das wirklich cool wäre, wenn ich es in meinen if-elif-else-Steuerelementen hätte.

if condition:
    stuff()
elif condition:
    otherstuff()
then:
    stuff_that_applies_to_both()
else:
    stuff_that_doesnt_aply_to_either()

Im Grunde genommen thenwird a ausgeführt, wenn eine der Bedingungen ausgeführt wird, AUSSER die else-Bedingung. Halten Sie das für nützlich? Es ähnelt dem Try-außer-else von Python.

Ich denke, einige von Ihnen wählen keine sehr vorläufige Implementierung aus. Der thenBlock wäre genau wie der elseBlock in einem try-exceptBlock in Python. Der wahre Grund, warum ich dies vorschlage, ist für solche Situationen.

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

Der thenBlock ist auf den ersten Bereich beschränkt, wenn er genau so elseist wie der . Das Verschachteln funktioniert also einwandfrei. Und wenn Sie vor den if-Anweisungen eine Methode ausführen müssen, hat das wirklich nichts mit diesem Anwendungsfall zu tun.

Ich finde es schrecklich. Wenn Sie möchten, dass Code nach einer Vielzahl von Bedingungen ausgeführt wird, überprüfen Sie entweder (a) diese Bedingungen erneut oder (b) setzen Sie eine Variable auf den angegebenen Erfolgsstatus.

Im Allgemeinen können Sie dies bereits mit einem Schalter / Gehäuse tun, und ein Schalter / Gehäuse bietet eine genauere Kontrolle über das, was Sie vorschlagen.

Es liest sich auch logisch nicht richtig. Wenn A sonst, wenn B, dann C. Bedeutet für jemanden nicht, dass C ausgeführt wird, wenn entweder A oder B als wahr bewertet werden.

Interessant, scheint mir aber (zugegebenermaßen etwas in meiner Art) eine Einladung zu Lesbarkeits-, Logik- und Syntaxproblemen zu sein.

Edit: Dein if-elif ist sehr einfach - was wäre, wenn es 10 elifs gäbe? 20? Müssten alle Bedingungen wahr sein? Wie stehen die Chancen dafür?
Dein If-Elif ist sehr einfach - was wäre, wenn es 10 Elifs gäbe? 20? Wäre das nicht ziemlich unlesbar?

Kann auch leicht durch bewährte und etablierte Methoden erreicht werden:

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

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

Was passiert, wenn "stuff_that_applies_to_both" vor den einzelnen Schritten geschehen muss? Ihr Code behandelt diesen Fall nicht:

if (thisCondition or thatCondition)
{
  stuff_that_applies_to_both();

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

Schließlich ermöglicht diese Syntax eine größere Flexibilität bei mehr Bedingungen: if (thisCondition oder thatCondition oder 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();
}

Ich habe if / else verwendet, hätte aber genauso einfach eine switch-Anweisung mit einem Flag verwenden können:

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();

Beachten Sie, dass ich das ConditionApplies-Flag eigentlich nicht brauchte - ich hätte die Funktion "stuff_that_applies_to_both ()" zu beiden nicht standardmäßigen Bedingungen hinzufügen können - ich habe dies nur getan, damit es eher wie die oben definierte Syntax aussieht, obwohl das "dann" eher als das "sonst".

Daher scheint es mir eine sehr spezialisierte Syntax zu sein, bei der eine allgemeinere Syntax die Rechnung erfüllt und mehr.

+1 für das Nachdenken über eine mögliche Funktion (mach das weiter!), Aber ich würde nicht dafür stimmen, sie zu implementieren.

Es würde mir nichts ausmachen, so etwas heute selbst zu benutzen. Aber um sicher zu gehen, würde ich es ungefähr so ​​oft verwenden, wie ich bis.

Code würde ohne die überflüssige Verschachtelung zumindest besser aussehen. Obwohl ich lieber Else Ifauf elif. Ich würde das Thenmit Dound das Finale Elsedurch ersetzen Otherwise.

Es scheint eine coole Idee zu sein. Das einzige Problem, das ich mir vorstelle, ist, dass Sie anfälliger für Fehler sind. Als würde man ein if / else if schreiben und dann blah () aufrufen. Schreiben Sie ein zusätzliches else, wenn das nicht bla will, entfernen Sie bla von dann und fügen Sie es Ihren ifs / elseifs hinzu. Wenn Sie oder ein anderer Programmierer eine weitere Anweisung hinzufügen, können Sie erwarten, dass blah aufgerufen wird, aber nicht.

Oder Sie können mehrere Wenns haben, ein Bla schreiben und alle Wenns vergessen, außer einem, das dies erfordert, was etwas kaputt machen würde. Es besteht auch die Möglichkeit, dass Sie ihnen folgen müssen, wenn Sie sie unter den if-Block stellen. Setzen Sie möglicherweise einen Bool in else (NoUpdate = true) und schreiben Sie einfach ein if (! NoUpdate) {} direkt darunter, das klarer ist und durch ein if gesetzt werden kann

Ich sage nur, dass es anfälliger für Fehler zu sein scheint, nicht dass mir die Idee nicht gefällt. Es würde mir nichts ausmachen, es in einer Sprache zu sehen, aber ich kann mir keine Situation vorstellen, in der ich es verwenden würde, wenn meine Sprache es unterstützt.

Ich finde Ihre Syntax verwirrend, aber ich sehe einen gewissen Wert im Konzept. Wenn ich über das Problem nachgedacht habe, habe ich konzeptionell einen "Unelse" gefunden, der im Grunde genommen Dinge in den Fällen ausführt, in denen der letzte elsenicht ausgelöst hat . Wenn ich es aus diesem Blickwinkel betrachte, würde ich vorschlagen, dass man ein ähnliches Ergebnis erzielen könnte über:

  tun
  {
    if (Bedingung1)
      ... Zeug nur für Bedingung1
    sonst wenn (Bedingung2)
      ... Zeug nur für Bedingung2
    sonst
    {
      ... Zeug für keine Bedingung
      brechen;
    }}
    ... Zeug für beide Bedingungen
  } while (0); // Fortsetzungspunkt für Pause

Eine andere Option kann in einigen Fällen sein:

  if ((Bedingung1 && (Aktion1,1)) ||
       (Bedingung2 && (Aktion2,1)) ||
       (action_for_neither, 0))
    action_for_either;

Ein bisschen böse aussehend, aber in einigen Fällen gibt es möglicherweise keine gute Möglichkeit, die gewünschte Abfolge von Ereignissen auszudrücken goto, außer Code zu duplizieren oder zu verwenden (was möglicherweise nicht so schlecht ist, außer für den Cartoon, den jemand hier einfügt).