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


11

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.


Wie verschachtelt kann das sein?
Aggietech

6
+1 für das Denken über den Tellerrand hinaus, aber ich würde nicht dafür stimmen, es tatsächlich umzusetzen. Siehe meine Antwort warum unten.
Wonko the Sane

1
Also 'dann' verhält es sich wie finallyin Java?
Alex Feinman

1
Ich finde thendas etwas verwirrend. Normalerweise thenwird impliziert, dass nach einem if. Ich meine, Sie sagen, if condition, then stuff()aber dann fahren Sie fort zu sagenthen stuff that applies to both
Matt Olenik

2
+1 für eine interessante Gedankenübung, aber ich stimme den Antworten zu, die dies unter Bad Idea einreichen. Es ist einfach nicht intuitiv und ich konnte sehen, dass dies WIRKLICH einige Codierer auslöst.
BlairHippo

Antworten:


17

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.


2
Ich stimme zu - sehr schwer zu verstehen, was es bedeutet, ohne eine Erklärung, wie Sie sie gegeben haben.
Tcrosley

Warum ist eine Erklärung, wie etwas funktioniert, zu viel zu erwarten?
Falmarri

5
Weil es das Lesen von Code erschwert.
Antsan

Ich bin mir nicht sicher, ob das fair ist. Jedes Konstrukt im Code muss einmal erklärt werden.
Magus

14

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.


2
Python hat keine switch / case-Anweisungen
Falmarri

2
Ich glaube nicht, dass die Frage direkt in Richtung Python formuliert wurde, aber wenn dies die Absicht war, markieren Sie sie bitte auch als Python.
Brian R. Bondy

Nun, es ist nicht direkt in Richtung Python formuliert. Das Beispiel war in Python. Aber wenn Ihre Antwort darauf, warum dies nicht benötigt wird, "es gibt switch-Anweisungen" lautet, hat Python diese nicht.
Falmarri

1
@ Falmarri: Fair genug, also denke ich, meine Antwort darauf wäre, dass Python besser wäre, um klassische switch-Anweisungen zu unterstützen.
Brian R. Bondy

Der Code in der Frage in Python bedeutet nicht, dass es sich bei der Frage um Python handelt, da dies auch Pseudocode sein kann. Wenn es nur um Python geht, sollte es als solches markiert werden
phuclv

8

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.


1
+1 für "bewährte und etablierte Methodik" - wenn es eine vernünftige Lösung für ein Problem gibt, ist es normalerweise am besten, sie zu verwenden :)
Bedwyr

what if there were 10 elifs? 20? Would all conditions need to be true?Das ist nicht möglich. Nur 1 Elif kann wahr sein, weil es aufhört, mehr auszuwerten.
Falmarri

Mein Fehler - ich habe es als "und" gelesen, als du "oder" gemeint hast. Ich stehe jedoch zu meiner Antwort - ich werde sie von dem aktualisieren, worauf Sie hingewiesen haben.
Wonko the Sane

Denken Sie wirklich, dass die Syntax, die Sie hier gepostet haben, klarer ist als von mir vorgeschlagen? Sie überprüfen nicht nur Ihre Bedingungen zweimal, sondern Nicht-Verschachtelung ist immer besser als Verschachtelung
Falmarri

1
Wie auch Ihre, es sei denn, Ihr "Dann" gilt wirklich für alle Bedingungen, die, wenn Sie mehr und mehr hinzufügen, immer weniger wahrscheinlich werden. Und ich persönlich komme aus einem C / C ++ / C # -Hintergrund und finde das Verschachteln weniger verwirrend als die geteilte Syntax (dh hier oben im "Wenn" oder vielleicht in einem "Elsif" etwas tun und dann nach unten springen und etwas tun sonst im "damals". Ich persönlich finde die Syntax besser lesbar, um alle Bedingungen zusammen zu haben. Könnte nicht richtig sein, aber es ist ein etablierteres Konzept in meiner täglichen Welt.
Wonko the Sane

2

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.


Nun, sprich mit den Machern von Python, nicht mit mir =]
Falmarri

Oh, ich dachte du entwirfst eine neue Sprache. Ich habe nur vorgeschlagen, die Namen zu ändern, um genauer zu sein. Lassen Sie elif, wenn Sie möchten, aber das letzte andere scheint sich von einem normalen anderen zu unterscheiden.
Peter Turner

Nun, es ist nicht unbedingt für eine neue Sprache, aber es ist auch nicht unbedingt für Python. Nur eine neue Idee für eine Syntaxregel im Allgemeinen. Dies kann auf jede Sprache mit relativ wenigen Nebenwirkungen angewendet werden.
Falmarri

0

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.


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 ifDies ist genau das, was dies verhindern soll. Das ist der springende Punkt einer elif-Aussage. Elif ist auch nicht notwendig, es kann mit if-Anweisungen überprüft werden, aber es wird kompliziert.
Falmarri

0

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

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.