Ternärer Operator als schädlich eingestuft? [geschlossen]

Würden Sie zum Beispiel diesen Einzeiler bevorzugen?

int median(int a, int b, int c) {
    return (a<b) ? (b<c) ? b : (a<c) ? c : a : (a<c) ? a : (b<c) ? c : b;
}

oder eine if / else-Lösung mit mehreren return-Anweisungen?

Wann ist es ?:angebracht und wann nicht? Sollte es Anfängern beigebracht oder verborgen werden?

Ist der ternäre Operator böse?

Nein, es ist ein Segen.

Wann ist?: Angemessen?

Wenn es so einfach ist, möchten Sie nicht viele Zeilen verschwenden.

und wann ist es nicht?

Wenn die Lesbarkeit und Klarheit des Codes leidet und die Gefahr eines Fehlers durch unzureichende Beachtung steigt, zum Beispiel bei vielen verketteten Operatoren, wie in Ihrem Beispiel.

Der Lackmustest ist, wenn Sie anfangen zu bezweifeln, dass Ihr Code auf lange Sicht leicht lesbar und wartbar ist. Dann tu es nicht.

Ich denke, der nicht verschachtelte ternäre Operator (dh eine Anweisung, bei der er nur einmal verwendet wird) ist in Ordnung, aber wenn Sie mehr als einen verschachteln, wird es etwas schwer zu lesen.

Wann ist?: Angemessen

• Wenn es Ihren Code übersichtlicher und lesbarer macht.

und wann ist es nicht?

• Wenn es Ihren Code unlesbar macht.
• Wenn Sie es nur tun, um ein Refactoring-Tool wie ReSharper und nicht die Person, die den Code warten muss, zufrieden zu stellen

Wenn Sie innerhalb des ternären Ausdrucks Logik- oder Funktionsaufrufe haben, macht es das Anschauen fürchterlich.

Ein Unterschied, auf den (meiner Meinung nach) niemand hingewiesen hat, ist, dass if-else keinen Wert zurückgeben kann, wohingegen der ternäre Operator dies kann.

Wenn ich von F # komme, verwende ich manchmal gerne den ternären Operator, um den Mustervergleich nachzuahmen.

match val with
| A -> 1
| B -> 3
| _ -> 0

vs

return val == A ? 1 : 
       val == B ? 3 : 
       0;

Ein Beispiel (IMHO) einer gültigen Verwendung:

printf("Success in %d %s\n", nr_of_tries, (nr_of_tries == 1 ? "try" : "tries"));

Dies führt zu besser lesbarem Code als zwei unterschiedliche print-Anweisungen. Verschachtelte Beispiele sind abhängig von: (verständlich? Ja: nein)

Absolut nicht böse. Tatsächlich ist es rein und wenn, dann nicht.

In funktionalen Sprachen wie Haskell, F #, ML usw. gelten die Wenn-Dann-Sonst-Aussagen als böse.

Der Grund dafür ist, dass Sie bei jeder "Aktion" wie einer zwingenden if-then-else-Anweisung eine Variablendeklaration von ihrer Definition trennen müssen und den Status in Ihre Funktion einführen müssen.

Zum Beispiel im folgenden Code:

const var x = n % 3 == 1
    ? Parity.Even
    : Parity.Odd;

gegen

Parity x;
if (n % 3 == 1)
    x = Parity.Even;
else
    x = Parity.Odd;

Der erste hat zwei Vorteile, abgesehen davon, dass er kürzer ist:

1. x ist eine Konstante und bietet daher viel weniger Chancen, Fehler einzuführen, und kann möglicherweise in einer Weise optimiert werden, wie es die zweite niemals sein könnte.
2. Der Typ wird durch den Ausdruck verdeutlicht, sodass der Compiler mühelos schließen kann, dass xer vom Typ sein muss Parity.

Verwirrenderweise wird der ternäre Operator in funktionalen Sprachen oft als Wenn-Dann-Sonst bezeichnet. In Haskell könnte man sagen x = if n mod 3 == 1 then Odd else Even.

Dieser besondere Ausdruck macht meine Augen weh; Ich würde jeden Entwickler in meinem Team auspeitschen, der es benutzt, weil es nicht zu warten ist.

Ternäre Operatoren sind nicht schlecht, wenn sie gut verwendet werden. Sie müssen nicht einmal einzelne Zeilen sein. Eine lange, gut formatierte Datei kann sehr klar und leicht zu verstehen sein:

return
      ( 'a' == $s ) ? 1
    : ( 'b' == $s ) ? 2
    : ( 'c' == $s ) ? 3
    :                 4;

Das gefällt mir besser als die äquivalente if / then / else-Kette:

if ( 'a' == $s ) {
    $retval = 1;
}
elsif ( 'b' == $s ) {
    $retval = 2;
}
elsif ( 'c' == $s ) {
    $retval = 3;
}
else {
    $retval = 4;
}

return $retval;

Ich formatiere diese in:

if    ( 'a' == $s ) { $retval = 1; }
elsif ( 'b' == $s ) { $retval = 2; }
elsif ( 'c' == $s ) { $retval = 3; }
else                { $retval = 4; }

return $retval;

wenn die Bedingungen und Zuordnungen eine einfache Ausrichtung ermöglichen. Trotzdem bevorzuge ich die ternäre Version, weil sie kürzer ist und nicht so viel Lärm um die Bedingungen und Aufgaben hat.

ReSharper in VS.NET schlägt manchmal vor, durch if...elseden ?:Operator zu ersetzen .

Es scheint, dass ReSharper nur vorschlägt, wenn die Bedingungen / Blöcke unter einem bestimmten Komplexitätsniveau liegen, ansonsten bleibt es dabei if...else.

Dies kann so umformatiert werden, dass es genauso gut aussieht wie die Kombination if / else:

int median(int a, int b, int c)
{
    return
        (a<b)
        ?
            (b<c)
            ? b
            :
                (a<c)
                ? c
                : a
        :
            (a<c)
            ? a
            :
                (b<c)
                ? c
                : b;
}

Das Problem ist jedoch, dass ich nicht wirklich sicher bin, ob ich die Einrückung richtig verstanden habe, um darzustellen, was tatsächlich passieren wird. :-)

Weit davon entfernt, böse zu sein, ist der ternäre Operator ein Glücksfall.

• Dies ist am nützlichsten, wenn Sie eine Entscheidung in einem verschachtelten Ausdruck treffen möchten . Das klassische Beispiel ist ein Funktionsaufruf:

  printf("I see %d evil construct%s in this program\n", n, n == 1 ? "" : "s");
  

• In Ihrem speziellen Beispiel ist das Ternär fast unbegründet, da es der Ausdruck auf oberster Ebene unter a ist return. Sie können die Bedingung auf Anweisungsebene aufheben, ohne etwas anderes als das returnSchlüsselwort zu duplizieren .

NB Nichts wird jemals diesen bestimmten Algorithmus für den Median leichter lesbar machen.

1. Abgesehen von "schlechten" Argumenten habe ich meiner Erfahrung nach eine hohe Korrelation zwischen der Verwendung des ternären Operators durch einen Programmierer und der Wahrscheinlichkeit festgestellt, dass die gesamte Codebasis schwer zu lesen, zu verfolgen und zu pflegen ist (wenn nicht völlig undokumentiert). Wenn es einem Programmierer mehr darum geht, ein paar Zeilen mit ein bis zwei Zeichen zu speichern, als jemand, der seinen Code verstehen kann, ist jede kleine Verwirrung, die eine ternäre Aussage versteht, normalerweise die Spitze des Eisbergs.

2. Ternäre Operatoren ziehen magische Zahlen an, wie sie Fliegen anziehen.

Wenn ich nach einer Open Source-Bibliothek suchte, um ein bestimmtes Problem zu lösen, und Code wie die ternären Operatoren des ursprünglichen Posters in einem Kandidaten für diese Bibliothek sah, würden Warnglocken in meinem Kopf losgehen und ich würde darüber nachdenken, weiterzumachen zu einem anderen Projekt auszuleihen.

Hier ist ein Beispiel dafür , wann es ist böse:

oldValue = newValue >= 0 ? newValue : oldValue;

Es ist verwirrend und verschwenderisch. Der Compiler konnte den zweiten Ausdruck (oldValue = oldValue) optimieren, aber warum hat der Codierer dies überhaupt getan?

Ein anderer doozy:

thingie = otherThingie != null ? otherThingie : null;

Manche Leute sind einfach nicht als Programmierer gedacht ...

Greg sagt, dass die äquivalente if-Anweisung 'noisy' ist. Es ist, wenn Sie es laut schreiben. Aber das gleiche, wenn geschrieben werden kann als:

if ('a' == $s) return 1;
if ('b' == $s) return 2;
if ('c' == $s) return 3;
return 4;

Welches ist nicht lauter als die ternäre. Ich frage mich, ob die ternären Abkürzungen; Werden alle Ausdrücke ausgewertet?

Böse? Sieh mal, sie sind einfach anders.

ifist eine Aussage. (test ? a : b)ist ein Ausdruck. Sie sind nicht dasselbe.

Ausdrücke existieren, um Werte auszudrücken. Anweisungen sind vorhanden, um Aktionen auszuführen. Ausdrücke können in Anweisungen vorkommen, aber nicht umgekehrt. Sie können also ternäre Ausdrücke in anderen Ausdrücken verwenden, z. B. für Ausdrücke in einer Summierung oder für Argumente für eine Methode. Sie müssen nicht müssen , aber Sie können , wenn Sie wollen . Daran ist nichts auszusetzen. Manche Leute mögen sagen, das sei böse, aber das ist ihre Meinung.

Ein Wert eines ternären Ausdrucks besteht darin, dass Sie sowohl wahre als auch falsche Fälle behandeln können. ifAussagen nicht.

Wenn Sie sich Sorgen um die Lesbarkeit machen, können Sie diese lesbar formatieren.

Irgendwie hat sich "Übel" in das Programmiervokabular eingeschlichen. Ich würde gerne wissen, wer es zuerst fallen gelassen hat. (Eigentlich habe ich einen Verdacht - er ist am MIT.) Es wäre mir lieber, wenn wir objektive Gründe für Werturteile in diesem Bereich hätten, nicht nur den Geschmack und die Namen der Menschen.

Es hat einen Platz. Ich habe in vielen Unternehmen gearbeitet, in denen die Fähigkeiten von Entwicklern von schrecklich bis hin zu Zauberern reichen. Da der Code gewartet werden muss und ich nicht für immer da sein werde, versuche ich, Dinge so zu schreiben, dass es so aussieht, als ob sie dorthin gehören (ohne die Kommentare mit meinen Initialen zu betrachten, ist es äußerst selten, dass Sie dazu in der Lage sind Schauen Sie sich den Code an, an dem ich gearbeitet habe, um zu sehen, wo ich Änderungen vorgenommen habe.

Während der ternäre Operator witzig und cool aussieht, ist es meiner Erfahrung nach unmöglich, die Codezeile zu warten. Bei meinem jetzigen Arbeitgeber haben wir Produkte, die seit fast 20 Jahren ausgeliefert werden. Ich würde dieses Beispiel nirgendwo verwenden.

Ich denke nicht, dass der ternäre Operator böse ist.

Hier ist jedoch eine GOTCHA, die mich verblüfft hat. Ich war ein C-Programmierer für viele (10+) und in den späten 1990er Jahren wechselte ich in die webbasierte Anwendungsprogrammierung. Als Webprogrammierer bin ich bald auf PHP gestoßen, das auch einen ternären Operator hat. Ich hatte einen Fehler in einem PHP-Programm, den ich schließlich auf eine Codezeile mit einem verschachtelten ternären Operator zurückführte. Es stellt sich heraus, dass der ternäre PHP-Operator von links nach rechts verknüpft, der ternäre C-Operator (an den ich gewöhnt war) jedoch von rechts nach links verknüpft.

Alles, was Ihren Code hässlicher macht, ist böse.

Wenn Sie ternary verwenden, um Ihren Code sauberer zu machen, verwenden Sie es auf jeden Fall. Manchmal ist es in wie PHP großartig, Inline-Ersetzungen vorzunehmen, z

"Hello ".($Male?"Mr":"Ms")." $Name

Das spart ein paar Zeilen, und es ist ziemlich klar, aber Ihr Beispiel muss zumindest besser formatiert werden, um klar zu sein, und ternär ist nicht wirklich gut für mehrzeilige, dann können Sie auch if / else verwenden.

Kann ich das sagen Ich kann diese spezielle Anwendung der ternären Operation nicht böse finden :

1. Die Operation, die es durchführt, ist ziemlich trivial, und wenn Sie sie einmal durchlaufen haben, ist es kaum möglich, dass einige Bugs herauskommen.
2. was es tut, steht klar im Funktionsnamen;
3. > 1 Zeile für etwas zu nehmen, das so offensichtlich ist und das in Zukunft nicht so deutlich verbessert werden würde (es sei denn, ein magischer Median-Algorithmus hat bis jetzt unentdeckt gelebt).

Bitte erbarme dich, mein Ruf ist schon ziemlich erbärmlich.

Größter Gewinn: Zeigen, dass es ein einziges Aktionsziel gibt.

if ( $is_whatever )
    $foo = 'A';
else
    $foo = 'B';

Es gibt zwei Codepfade, denen Sie folgen können, und der Leser muss sorgfältig lesen, um festzustellen, welche beiden Variablen festgelegt werden. In diesem Fall ist es nur eine Variable, aber der Leser muss mehr lesen, um das herauszufinden. Immerhin könnte es das gewesen sein:

if ( $is_whatever )
    $foo = 'A';
else
    $bar = 'B';

Mit dem ternären Operator ist klar, dass nur eine Variable gesetzt wird.

$foo = $is_whatever ? 'A' : 'B';

Auf der untersten Ebene ist es das DRY-Prinzip (Don't Repeat Yourself) in seiner grundlegendsten Form. Wenn Sie $foonur einmal angeben können , tun Sie dies.

Wenn ... dann ... sonst dazu neigt, die Bedingung zu betonen und daher die Operationen, die unter bestimmten Bedingungen ausgeführt werden, zu deaktivieren.

Der ternäre Operator ist das Gegenteil, er neigt dazu, die Bedingung zu verbergen und ist daher nützlich, wenn die auszuführende Operation wichtiger ist als die Bedingung selbst.

In einigen Sprachen gibt es das kleine technische Problem, dass sie nicht ganz miteinander verwechselt werden können, da es sich um eine Anweisung und einen Ausdruck handelt, z. B. um das bedingte Initialisieren von Konstanten in C ++

Wann ist es angebracht und wann nicht?

Ich denke, dass es bei der Entwicklung für eine homogene Gruppe von Menschen kein Problem gibt, aber wenn Sie mit Menschen zu tun haben, die mit unterschiedlichen Ebenen umgehen, führt diese Art von Onelinern nur eine weitere Ebene von Komplexität in den Code ein. Meine Richtlinie in dieser Angelegenheit lautet also: Code klar und nicht erklären, anstatt Code kurz und 123123-mal erklären.

Sollte es Anfängern beigebracht oder verborgen werden?

Anfängern sollte ich nicht beigebracht werden, sondern sie sollten es vorziehen, es herauszufinden, wenn es nötig ist, so dass es nur verwendet wird, wenn es notwendig ist und nicht jedes Mal, wenn Sie ein Wenn benötigen.

IMO, der Operator selbst ist nicht böse, aber die dafür in C (und C ++) verwendete Syntax ist zu knapp. IMO, Algol 60 hat es besser gemacht, also ungefähr so:

A = x == y ? B : C;

würde eher so aussehen (aber generell an der C-ähnlichen Syntax festhalten):

A = if (x==y) B else C;

Trotzdem kann ein zu tiefes Verschachteln zu Problemen mit der Lesbarkeit führen, aber zumindest A) kann es jeder, der das Programmieren überhaupt abgeschlossen hat, leicht herausfinden, und B) Leute, die es verstehen, können ein wesentlich tieferes Verschachteln ziemlich leicht handhaben. OTOH, ich würde auch bemerken, dass in LISP (zum Beispiel) a condeiner ternären Aussage ziemlich ähnlich ist - keine Menge von Aussagen, sondern ein einzelner Ausdruck, der einen Wert ergibt (andererseits ist der größte Teil von LISP so .. .)

Ein Geschäft, das regelmäßig 600-1200-Zeilen-Methoden schreibt, sollte mir nicht sagen, dass ein Ternär "schwer zu verstehen" ist. Jeder Shop, in dem regelmäßig fünf Bedingungen zur Auswertung eines Code-Zweigs zugelassen sind, sollte mir nicht sagen, dass konkret zusammengefasste Bedingungen in einem Ternär "schwer zu lesen" sind.

Wann ist?: Angemessen und wann nicht?

• Wenn Sie keinen Leistungsgewinn erzielen, verwenden Sie ihn nicht. Dies wirkt sich auf die Lesbarkeit Ihres Codes aus.
• Verwenden Sie es einmal und verschachteln Sie es nicht.
• Es ist schwieriger zu debuggen.

Sollte es Anfängern beigebracht oder verborgen werden?

Egal, aber es sollte nicht absichtlich versteckt werden, da es nicht zu komplex ist, um von einem „Anfänger“ gelernt zu werden.

In deinem Beispiel:

def median(a, b, c):
    if a < b < c: return b
    if a < c < b: return c
    if b < a < c: return a
    if b < c < a: return c
    if c < a < b: return a
    if c < b < a: return b

ist sehr einfach zu lesen und offensichtlich. Die Variable zwischen dem <<ist der Rückgabewert.

Aktualisieren

gleich, aber weniger Codezeilen. Immer noch einfach, denke ich.

def median(a, b, c):
    if b<a<c or c<a<b: return a
    if a<b<c or c<b<a: return b
    if a<c<b or b<c<a: return c

Es ist auch notwendig für const

const int nLegs  = isChicken ? 2: 4 ;