Zu ternär oder nicht zu ternär? [geschlossen]

Ich persönlich bin ein Anwalt des ternären Operators: ()? :; Mir ist klar, dass es seinen Platz hat, aber ich bin auf viele Programmierer gestoßen, die völlig dagegen sind, es jemals zu benutzen, und auf einige, die es zu oft benutzen.

Was denkst du darüber? Welchen interessanten Code haben Sie bei der Verwendung gesehen?

Verwenden Sie es nur für einfache Ausdrücke :

int a = (b > 10) ? c : d;

Verketten oder verschachteln Sie keine ternären Operatoren, da diese schwer zu lesen und verwirrend sind:

int a = b > 10 ? c < 20 ? 50 : 80 : e == 2 ? 4 : 8;

Wenn Sie einen ternären Operator verwenden, sollten Sie den Code so formatieren, dass die Lesbarkeit verbessert wird:

int a = (b > 10) ? some_value                 
                 : another_value;

Dies erschwert das Debuggen etwas, da Sie nicht für jeden der Unterausdrücke Haltepunkte setzen können. Ich benutze es selten.

Ich liebe sie, besonders in typsicheren Sprachen.

Ich sehe nicht wie das:

int count = (condition) ? 1 : 0;

ist schwieriger als das:

int count;

if (condition)
{
  count = 1;
} 
else
{
  count = 0;
}

bearbeiten -

Ich würde argumentieren, dass ternäre Operatoren alles weniger komplex und ordentlicher machen als die Alternative.

Verkettet geht es mir gut mit - verschachtelt, nicht so sehr.

Ich neige dazu, sie eher in C zu verwenden, einfach b / c, sie sind eine if-Anweisung, die Wert hat, so dass unnötige Wiederholungen oder Variablen vermieden werden:

x = (y < 100) ? "dog" :
    (y < 150) ? "cat" :
    (y < 300) ? "bar" : "baz";

eher, als

     if (y < 100) { x = "dog"; } 
else if (y < 150) { x = "cat"; }
else if (y < 300) { x = "bar"; } 
else              { x = "baz"; }

Bei solchen Aufgaben finde ich, dass es weniger umgestaltet und klarer ist.

Wenn ich dagegen in Rubin arbeite, verwende ich eher, if...else...endweil es auch ein Ausdruck ist.

x =   if (y < 100) then "dog"
    elif (y < 150) then "cat"
    elif (y < 300) then "bar"
    else                "baz"
    end

(obwohl ich zugegebenermaßen für etwas so Einfaches sowieso nur den ternären Operator verwenden könnte).

Der ternäre ?:Operator ist lediglich ein funktionales Äquivalent des Verfahrensif Konstrukts. Solange Sie keine verschachtelten ?:Ausdrücke verwenden, gelten hier die Argumente für / gegen die funktionale Darstellung einer Operation. Das Verschachteln von ternären Operationen kann jedoch zu Code führen, der geradezu verwirrend ist (Übung für den Leser: Versuchen Sie, einen Parser zu schreiben, der verschachtelte ternäre Bedingungen verarbeitet, und Sie werden deren Komplexität zu schätzen wissen).

Es gibt jedoch viele Situationen, in denen eine konservative Verwendung des ?:Operators zu Code führen kann, der tatsächlich leichter zu lesen ist als sonst. Beispielsweise:

int compareTo(Object object) {
    if((isLessThan(object) && reverseOrder) || (isGreaterThan(object) && !reverseOrder)) {
       return 1;
    if((isLessThan(object) && !reverseOrder) || (isGreaterThan(object) && reverseOrder)) {
       return -1;
    else
      return 0;              
}

Vergleichen Sie das jetzt damit:

int compareTo(Object object) {
    if(isLessThan(object))
        return reverseOrder ? 1 : -1;         
    else(isGreaterThan(object))
        return reverseOrder ? -1 : 1;
    else        
       return 0;              
}

Da der Code kompakter ist, gibt es weniger syntaktisches Rauschen, und wenn der ternäre Operator mit Bedacht verwendet wird ( dh nur in Bezug auf die Eigenschaft reverseOrder ), ist das Endergebnis nicht besonders knapp.

Es ist wirklich eine Frage des Stils; Die unbewussten Regeln, denen ich folge, sind:

• Bewerten Sie nur 1 Ausdruck - also foo = (bar > baz) ? true : false , aber NICHTfoo = (bar > baz && lotto && someArray.Contains(someValue)) ? true : false
• Wenn ich es für die Anzeigelogik verwende, z <%= (foo) ? "Yes" : "No" %>
• Verwenden Sie es nur wirklich für die Zuordnung; Fließ niemals Logik (also niemals(foo) ? FooIsTrue(foo) : FooIsALie(foo) ) Flusslogik im Ternären ist selbst eine Lüge, ignorieren Sie diesen letzten Punkt.

Ich mag es, weil es prägnant und elegant für einfache Zuweisungsoperationen ist.

Wie so viele Meinungsfragen lautet die Antwort unweigerlich: Es kommt darauf an

Für so etwas wie:

return x ? "Yes" : "No";

Ich denke, das ist viel prägnanter (und für mich schneller zu analysieren) als:

if (x) {
    return "Yes";
} else {
    return "No";
}

Wenn Ihr bedingter Ausdruck komplex ist, ist die ternäre Operation keine gute Wahl. Etwas wie:

x && y && z >= 10 && s.Length == 0 || !foo

ist kein guter Kandidat für den ternären Operator.

Abgesehen davon, wenn Sie ein C-Programmierer sind, hat GCC tatsächlich eine Erweiterung , mit der Sie den if-true-Teil des Ternärs wie folgt ausschließen können:

/* 'y' is a char * */
const char *x = y ? : "Not set";

Welche gesetzt xzu der yAnnahme ynicht NULL. Gutes Zeug.

In meinen Augen ist es nur dann sinnvoll, den ternären Operator zu verwenden, wenn ein Ausdruck benötigt wird.

In anderen Fällen scheint der ternäre Operator die Klarheit zu verringern.

Durch das Maß der zyklomatischen Komplexität sind die Verwendung von ifAnweisungen oder der ternäre Operator gleichwertig. Nach dieser Maßnahme lautet die Antwort also nein , die Komplexität wäre genau die gleiche wie zuvor.

Durch andere Maßnahmen wie Lesbarkeit, Wartbarkeit und DRY (Don't-Repeat-Yourself) kann sich eine Auswahl als besser als die andere erweisen.

Ich verwende es ziemlich oft an Orten, an denen ich gezwungen bin, in einem Konstruktor zu arbeiten - zum Beispiel in den neuen .NET 3.5 LINQ to XML-Konstrukten -, um Standardwerte zu definieren, wenn ein optionaler Parameter null ist.

Erfundenes Beispiel:

var e = new XElement("Something",
    param == null ? new XElement("Value", "Default")
                  : new XElement("Value", param.ToString())
);

oder (danke Asterit)

var e = new XElement("Something",
    new XElement("Value",
        param == null ? "Default"
                      : param.ToString()
    )
);

Unabhängig davon, ob Sie den ternären Operator verwenden oder nicht, ist es wichtig, dass Ihr Code lesbar ist. Jedes Konstrukt kann unlesbar gemacht werden.

Ich verwende den ternären Operator, wo immer ich kann, es sei denn, der Code ist dadurch extrem schwer zu lesen, aber das ist normalerweise nur ein Hinweis darauf, dass mein Code ein wenig umgestaltet werden könnte.

Es verwirrt mich immer wieder, wie manche Leute denken, der ternäre Operator sei ein "verstecktes" Merkmal oder etwas mysteriös. Es ist eines der ersten Dinge, die ich gelernt habe, als ich mit dem Programmieren in C angefangen habe, und ich glaube nicht, dass es die Lesbarkeit beeinträchtigt. Es ist ein natürlicher Teil der Sprache.

(Hack des Tages)

#define IF(x) x ?
#define ELSE :

Dann können Sie if-then-else als Ausdruck verwenden:

int b = IF(condition1)    res1
        ELSE IF(condition2)  res2
        ELSE IF(conditions3) res3
        ELSE res4;

Ich stimme jmulder zu: Es sollte nicht anstelle von a verwendet werden if, aber es hat seinen Platz für den Rückgabeausdruck oder innerhalb eines Ausdrucks:

echo "Result: " + n + " meter" + (n != 1 ? "s" : "");
return a == null ? "null" : a;

Ersteres ist nur ein Beispiel, es sollte eine bessere i18n-Unterstützung des Plural verwendet werden!

Wenn Sie den ternären Operator für eine einfache bedingte Zuweisung verwenden, ist dies meiner Meinung nach in Ordnung. Ich habe gesehen, dass es (ab) verwendet wird, um den Programmfluss zu steuern, ohne überhaupt eine Zuweisung vorzunehmen, und ich denke, das sollte vermieden werden. Verwenden Sie in diesen Fällen eine if-Anweisung.

Ich denke, der ternäre Operator sollte bei Bedarf verwendet werden. Es ist offensichtlich eine sehr subjektive Wahl, aber ich finde, dass ein einfacher Ausdruck (insbesondere als Rückgabeausdruck) viel klarer ist als ein vollständiger Test. Beispiel in C / C ++:

return (a>0)?a:0;

Verglichen mit:

if(a>0) return a;
else return 0;

Sie haben auch den Fall, dass die Lösung zwischen dem ternären Operator und dem Erstellen einer Funktion liegt. Zum Beispiel in Python:

l = [ i if i > 0 else 0 for i in lst ]

Die Alternative ist:

def cap(value):
    if value > 0:
        return value
    return 0
l = [ cap(i) for i in lst ]

Es wird genug benötigt, um in Python (als Beispiel) eine solche Redewendung regelmäßig zu sehen:

l = [ ((i>0 and [i]) or [0])[0] for i in lst ]

Diese Zeile verwendet die Eigenschaften der logischen Operatoren in Python: Sie sind faul und geben den zuletzt berechneten Wert zurück, wenn er dem Endzustand entspricht.

Ich mag sie. Ich weiß nicht warum, aber ich fühle mich sehr cool, wenn ich den ternären Ausdruck verwende.

Ich habe solche Bestien gesehen wie (es war tatsächlich viel schlimmer, da es ValidDate war und auch Monat und Tag überprüft wurde, aber ich konnte mir nicht die Mühe machen, mich an das Ganze zu erinnern):

isLeapYear =
    ((yyyy % 400) == 0)
    ? 1
    : ((yyyy % 100) == 0)
        ? 0
        : ((yyyy % 4) == 0)
            ? 1
            : 0;

wo eindeutig eine Reihe von if-Anweisungen besser gewesen wäre (obwohl diese immer noch besser ist als die Makroversion, die ich einmal gesehen habe).

Ich habe nichts dagegen für kleine Dinge wie:

reportedAge = (isFemale && (Age >= 21)) ? 21 + (Age - 21) / 3 : Age;

oder sogar etwas knifflige Dinge wie:

printf ("Deleted %d file%s\n", n, (n == 1) ? "" : "s");

Nun, die Syntax dafür ist schrecklich. Ich finde funktionale Wenns sehr nützlich und mache Code oft lesbarer.

Ich würde vorschlagen, ein Makro zu erstellen, um es besser lesbar zu machen, aber ich bin sicher, dass jemand einen schrecklichen Randfall entwickeln kann (wie es bei CPP immer der Fall ist).

Ich verwende gerne den Operator im Debug-Code, um Fehlerwerte zu drucken, damit ich sie nicht ständig nachschlagen muss. Normalerweise mache ich das für Debug-Drucke, die nicht mehr bleiben, wenn ich mit der Entwicklung fertig bin.

int result = do_something();
if( result != 0 )
{
  debug_printf("Error while doing something, code %x (%s)\n", result,
                result == 7 ? "ERROR_YES" :
                result == 8 ? "ERROR_NO" :
                result == 9 ? "ERROR_FILE_NOT_FOUND" :
                "Unknown");
}

Ich benutze den ternären Operator fast nie, denn wenn ich ihn benutze, denke ich immer viel mehr nach, als ich später tun muss, wenn ich versuche, ihn zu warten.

Ich mag es, Ausführlichkeit zu vermeiden, aber wenn es den Code viel einfacher macht, werde ich mich für die Ausführlichkeit entscheiden.

Erwägen:

String name = firstName;

if (middleName != null) {
    name += " " + middleName;
}

name += " " + lastName;

Das ist ein bisschen ausführlich, aber ich finde es viel lesbarer als:

String name = firstName + (middleName == null ? "" : " " + middleName)
    + " " + lastName;

oder:

String name = firstName;
name += (middleName == null ? "" : " " + middleName);
name += " " + lastName;

Es scheint einfach zu viele Informationen auf zu wenig Platz zu komprimieren, ohne klar zu machen, was los ist. Jedes Mal, wenn ich sehe, dass ternäre Operatoren verwendet werden, habe ich immer eine Alternative gefunden, die viel einfacher zu lesen schien. Andererseits ist dies eine äußerst subjektive Meinung. Wenn Sie und Ihre Kollegen ternäre Operatoren als sehr lesbar empfinden, entscheiden Sie sich dafür.

Nur wenn:

$ var = (simple> test? simple_result_1: simple_result_2);

KUSS.

Ich benutze normalerweise in solchen Dingen:

before:

if(isheader)
    drawtext(x,y,WHITE,string);
else
    drawtext(x,y,BLUE,string);

after:

    drawtext(x,y,isheader==true?WHITE:BLUE,string);

Wie andere betont haben, eignen sie sich gut für kurze, einfache Bedingungen. Ich mag sie besonders für Standardeinstellungen (ähnlich wie || und / oder Verwendung in Javascript und Python), z

int repCount = pRepCountIn ? *pRepCountIn : defaultRepCount;

Eine weitere häufige Verwendung ist das Initialisieren einer Referenz in C ++. Da Referenzen in derselben Anweisung deklariert und initialisiert werden müssen, können Sie keine if-Anweisung verwenden.

SomeType& ref = pInput ? *pInput : somethingElse;

Ich behandle ternäre Operatoren sehr wie GOTO. Sie haben ihren Platz, aber sie sollten normalerweise vermieden werden, um den Code verständlicher zu machen.

Ich habe kürzlich eine Variation von ternären Operatoren gesehen (na ja, irgendwie), die die Standardvariante "() ?:" Einen Inbegriff von Klarheit erscheinen lassen:

var Result = [CaseIfFalse, CaseIfTrue][(boolean expression)]

oder, um ein konkreteres Beispiel zu geben:

var Name = ['Jane', 'John'][Gender == 'm'];

Wohlgemerkt, dies ist Javascript, so dass solche Dinge in anderen Sprachen (zum Glück) möglicherweise nicht möglich sind.

Für einfache Fälle verwende ich es gerne. Tatsächlich ist es viel einfacher, beispielsweise als Parameter für Funktionen oder ähnliches zu lesen / zu codieren. Auch um die neue Zeile zu vermeiden, behalte ich gerne alle meine if / else.

Es wäre ein großes NEIN-NEIN in meinem Buch.

Also, weiter, für ein einzelnes, wenn / sonst werde ich den ternären Operator verwenden. In anderen Fällen ein reguläres if / else if / else (oder Schalter)

Ich mag Groovys Sonderfall des ternären Operators, genannt Elvis-Operator:?:

expr ?: default

Dieser Code wird als Ausdruck ausgewertet, wenn er nicht null ist, und als Standard, wenn dies der Fall ist. Technisch gesehen ist es kein ternärer Operator, aber es hängt definitiv damit zusammen und spart viel Zeit / Eingabe.

Für einfache Aufgaben wie das Zuweisen eines unterschiedlichen Werts je nach Bedingung sind sie großartig. Ich würde sie nicht verwenden, wenn es je nach Bedingung längere Ausdrücke gibt.

So viele Antworten haben gesagt, es kommt darauf an . Ich finde, wenn der ternäre Vergleich bei einem schnellen Scan des Codes nicht sichtbar ist, sollte er nicht verwendet werden.

Als Nebenproblem könnte ich auch bemerken, dass seine Existenz tatsächlich eine Anomalie ist, da in C Vergleichstests eine Aussage sind. In Icon ist das ifKonstrukt (wie die meisten Icon) tatsächlich ein Ausdruck. So können Sie Dinge tun wie:

x[if y > 5 then 5 else y] := "Y" 

... was ich viel lesbarer finde als ein ternery Vergleichsoperator. :-)

Vor kurzem gab es eine Diskussion über die Möglichkeit, den ?:Operator zu Icon hinzuzufügen , aber mehrere Leute wiesen zutreffend darauf hin, dass es aufgrund des Weges absolut keine Notwendigkeit gabif .

Das heißt, wenn Sie dies in C (oder einer der anderen Sprachen mit dem Ternery-Operator) tun könnten, würden Sie den Ternery-Operator überhaupt nicht benötigen.

Wenn Sie und Ihre Arbeitskollegen verstehen, was sie tun, und sie nicht in großen Gruppen erstellt werden, machen sie den Code meiner Meinung nach weniger komplex und leichter zu lesen, weil es einfach weniger Code gibt.

Ich denke, ternäre Operatoren erschweren das Verständnis von Code nur, wenn Sie mehr als 3 oder 4 in einer Zeile haben. Die meisten Menschen erinnern sich nicht daran, dass sie Vorrang haben, und wenn Sie einen Stapel davon haben, wird das Lesen des Codes zu einem Albtraum.