Ein überzeugendes Argument für den Kommaoperator

Der Kommaoperator ist einer der weniger bekannten Operatoren in C-ähnlichen Sprachen wie JavaScript und C++. Im Wesentlichen begrenzt es eine Folge von Ausdrücken und gibt nur das Ergebnis des letzten Ausdrucks zurück.

const a = 1;
const b = 2;
const c = 3;
const result = (a, b, c, 4, 5, 6, true);
console.log(result); // true

if (false, true) console.log('hello'); // hello

Dann ist es natürlich, sich zu fragen: Wann wäre es jemals sinnvoll, mehrere Ausdrücke in einer einzigen Zeile unterzubringen?Und selbst wenn es nützlich wäre, warum sollte eine durch Kommas getrennte Folge von Ausdrücken (in a einzelne Zeile) besser lesbar und wartbar sein als eine durch Semikolons getrennte Folge von Anweisungen (über mehrere Zeilen)? Wann sollten wir das eine dem anderen vorziehen?

Das sind Fragen, die ich im Laufe der Jahre nur schwer beantworten konnte, aber jetzt denke ich, dass ich endlich eine Antwort habe. In diesem Artikel präsentiere ich einen überzeugenden Fall – ehrlich gesagt vielleicht den einzigen – für den Kommaoperator.

Ein motivierendes Beispiel

Lassen Sie uns zunächst über den bedingten ternären Operator sprechen. Wie unten zu sehen ist, bewertet die Bedingung den Wert, wenn sie wahr ist. Andernfalls bewertet ein anderes. Der Schwerpunkt liegt hier auf dem Schlüsselwort „Auswertung“, da die Zweige nur dann ausgeführt werden, wenn ihre Bedingung erfüllt ist.

const result = condition ? value : another;

In den meisten Fällen ist es ordentlich und hübsch. Allerdings scheitert es, wenn wir eine komplexere Logik zwischen den Zweigen ausführen müssen, bevor den bedingten Wert zurückgibt. An dieser Stelle greifen wir auf diese unglückliche Perversion zurück:

let result; // Uninitialized! Yikes!
if (condition) {
    // Do some complex stuff in between...
    doSomething();
    // ...
    result = value; // Actual Assignment
} else {
    // Do other complex stuff in between...
    doAnotherThing();
    // ...
    result = another; // Actual Assignment
}
// Hopefully we didn't forget to initialize `result`!

Jetzt gibt es viele Probleme mit dieser Formulierung.

1. Das Ergebnis ist zunächst nicht initialisiert. Das ist zwar nicht grundsätzlich böse, aber eine einfache und bewährte Möglichkeit, Fehler aufgrund von Undefiniertheit zu vermeiden, besteht darin, Variablen einfach immer zu initialisieren.
2. Die Initialisierung des Ergebnisses befindet sich buchstäblich am Ende des Zweigs – weit entfernt von seiner Deklaration.
3. Am Ende der Bedingung hoffen wir besser, dass das Ergebnis sicher initialisiert wird. Wenn nicht wir, hoffen wir besser, dass unsere Teamkollegen dies gleichermaßen durchsetzen. Wenn nicht jetzt, hoffen wir besser, dass zukünftige Entwickler dies auch beibehalten!

Es gibt einen Weg, diese Einschränkung zu umgehen, wenn wir darauf bestehen, bedingte ternäre Ausdrücke zu verwenden. Wir müssen nur den Code in Funktionen umgestalten. Das ist definitiv leichter gesagt als getan. Dieses Gimmick wird sehr schnell alt!

function computeWrappedValue() {
    // ...
    return value;
}

function computeWrappedAnother() {
    // ...
    return another;
}

// How cumbersome!
const result = condition ? computeWrappedValue() : computeWrappedAnother();

Ausdrucksbasierte Programmiersprachen (wie Rust) bieten eine elegantere Lösung. Durch die Umklassifizierung der if Anweisung in einen if Ausdruck kann jeder Zweig ausgewertet werden und somit Werte zurückgeben, die später in einer Variablen gespeichert werden können.

// A conditional ternary operator thus looks like this. Each branch
// returns a value, which is captured by the `result` variable.
// We thus ensure that `result` is always initialized by construction.
let result = if condition { value } else { another };

// If we wanted to do something more complex, we use the same syntax.
let result = if condition {
    do_something();
    // In Rust, the last expression without a semicolon is the value
    // that will be "returned" by the overall `if` expression.
    result
} else {
    do_another_thing();
    another
};

Können wir das in C-ähnlichen Sprachen nachahmen? Sie haben wahrscheinlich schon lange vorhergesehen, wohin ich damit will, aber ja!

Ein überzeugender Fall

Was wir wollen, ist eine Möglichkeit, Anweisungen willkürlich auszuführen bevor innerhalb der Ternärzweige einen Wert zurückgibt. Nun, zu unserem Glück ist genau dafür der Kommaoperator da.

// Parenthesized for clarity.
const result = condition
    ? (doSomething(), value)       // evaluates to `value`
    : (doAnotherThing(), another); // evaluates to `another`

Das Schöne an dieser Formulierung ist die Tatsache, dass die Verzweigungsausdrücke nur bei Bedarf ausgewertet werden. Wir emulieren effektiv das Verhalten ausdrucksbasierter Programmiersprachen. Vorbei sind die Zeiten der Ad-hoc-Wrapper-Funktionen!

Aber leiderwir können mit dieser Technik nur bis zu einem gewissen Grad kommen. Sie können sich vorstellen, dass für einige ausreichend große n das Zusammenpacken von n Anweisungen in einer einzigen Zeile bereits danach schreit, in eine eigene Funktion umgestaltet zu werden. Persönlich würde ich es mir bereits zum Zeitpunkt n > noch einmal überlegen. 3. Alles, was darüber hinausgeht, ist im Hinblick auf die Lesbarkeit eine zweifelhafte Konstruktion.

// Maybe we should reconsider here?
const result = condition
    ? (x++, thing = hello(), doSomething(), value)
    : (++y, thing = world(), doAnotherThing(), another);

// Okay, stop. Definitely turn back now!
const result = condition
    ? (
        x++,
        thing = hello(),
        doSomething(),
        doMore(y),
        doEvenMore(thing),
        value,
    ) : (
        ++y,
        thing = world(),
        doAnotherThing(),
        doMore(y),
        doEvenMore(thing),
        another,
    );
// Unless, of course, you're fine with this. It kinda does
// look like a Rust `if` expression if you squint hard enough.

Abschluss

Abschließend haben wir einen überzeugenden Fall für den Kommaoperator gesehen: komplexe bedingte ternäre Operationen. Der Kommaoperator glänzt, wenn die Zweige kurz und bündig sind, kommt aber nach drei eingebundenen Anweisungen schnell aus der Mode. An diesem Punkt ist es wahrscheinlich besser, den Code umzugestalten.

Sollten Sie also Kommaoperatoren verwenden? Ehrlich gesagt... ja! Lesbarer Code berücksichtigt den nächsten Leser. Solange die Kommaketten also nie übermäßig lang sind, würde ich diesen Codierungsstil akzeptieren – und sogar fördern. Wenn wir die Alternativen berücksichtigen (d. h. nicht initialisierte Variablen und umgestaltete Mikrofunktionen), ist der Kommaoperator doch nicht so schlecht.

In der Praxis bestreue ich meine eigenen Codebasen bereits mit diesen komisch aussehenden Kommaoperatoren. Allerdings muss ich fairerweise sagen, dass ich sowieso selten einen Bedarf an ternären Bedingungen mit mehreren Anweisungen habe. Aber wenn ich das tue, habe ich ein cooles Werkzeug in meinem Gürtel, das meine Absicht prägnant zum Ausdruck bringt.

Zu diesem Zweck verweise ich auf meine überzeugenden Argumente für den Kommaoperator.

Das obige ist der detaillierte Inhalt vonEin überzeugendes Argument für den Kommaoperator. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!