Kes Menarik untuk Pengendali Koma

operator koma ialah salah satu pengendali yang kurang dikenali dalam bahasa seperti C seperti JavaScript dan C++. Pada asasnya, ia mengehadkan urutan ungkapan dan hanya mengembalikan hasil yang terakhir.

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

Adalah lumrah untuk bertanya: bilakah berguna untuk menjejalkan berbilang ungkapan dalam satu baris? Tambahan pula, walaupun ia berguna, mengapakah urutan ungkapan yang dipisahkan koma (dalam satu baris) menjadi lebih mudah dibaca dan diselenggara daripada urutan penyataan yang dipisahkan koma bertitik (merentasi beberapa baris)? Bilakah kita harus memilih satu daripada yang lain?

Ini adalah soalan yang sukar saya jawab selama ini, tetapi kini saya rasa saya akhirnya mempunyai jawapan. Dalam artikel ini, saya mengemukakan kes yang menarik—mungkin satu-satunya kes yang terus terang—untuk pengendali koma.

Contoh yang Memotivasikan

Mari kita bercakap tentang pengendali ternary bersyarat. Seperti yang dilihat di bawah, jika syarat itu benar, ia menilai nilai. Jika tidak, ia menilai yang lain. Terdapat penekanan dalam kata kunci "penilaian" di sini kerana cawangan hanya melaksanakan apabila syarat mereka dipenuhi.

const result = condition ? value : another;

Untuk kebanyakan kes, ia kemas dan cantik. Walau bagaimanapun, di mana ia runtuh ialah apabila kita perlu melakukan logik yang lebih kompleks di antara cawangan sebelum mengembalikan nilai bersyarat. Pada ketika ini, kami menggunakan penyelewengan yang malang ini:

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`!

Kini terdapat banyak isu dengan formulasi ini.

1. Hasilnya tidak diketahui pada mulanya. Ini sememangnya tidak jahat, tetapi cara yang mudah dicuba dan diuji untuk mengelakkan pepijat disebabkan oleh tidak ditentukan adalah dengan sentiasa memulakan pembolehubah.
2. Pemulaan hasil secara literal berada di bahagian bawah cawangan—jauh sekali daripada pengisytiharannya.
3. Menjelang akhir bersyarat, lebih baik kami berharap keputusan itu pasti dimulakan. Jika bukan kita, lebih baik kita berharap rakan sepasukan kita sama-sama melaksanakannya. Jika bukan sekarang, lebih baik kami berharap pembangun akan datang juga menyokongnya!

Terdapat cara mengatasi had ini jika kita berkeras untuk menggunakan ungkapan ternary bersyarat. Kita hanya perlu memfaktorkan semula kod ke dalam fungsi. Itu pasti lebih mudah diucapkan daripada dilakukan. Gimik ini menjadi tua dengan cepat!

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

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

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

Bahasa pengaturcaraan berasaskan ekspresi (seperti Rust) mempunyai penyelesaian yang lebih elegan. Dengan mengklasifikasikan semula penyataan sebagai jika ungkapan, setiap cawangan boleh dinilai dan dengan itu mengembalikan nilai yang kemudiannya boleh disimpan dalam pembolehubah.

// 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
};

Bolehkah kita mencontohi ini dalam bahasa seperti C? Anda mungkin telah lama meramalkan ke mana arah tuju saya dengan ini, tetapi ya!

Kes yang Menarik

Apa yang kita mahukan ialah cara untuk melaksanakan penyataan secara sewenang-wenangnya sebelum mengembalikan nilai dalam cawangan ternary. Nah, bertuah bagi kami, ini adalah tepat sekali gunanya pengendali koma.

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

Perkara yang kemas tentang formulasi ini adalah hakikat bahawa ungkapan cawangan hanya dinilai apabila perlu. Kami secara berkesan meniru tingkah laku bahasa pengaturcaraan berasaskan ekspresi. Sudah berlalu fungsi pembungkus ad hoc!

Tetapi sayangnya, kita hanya boleh pergi sejauh ini dengan teknik ini. Anda boleh bayangkan bahawa untuk beberapa n yang cukup besar, menjejalkan n pernyataan ke dalam satu baris sudah meminta untuk difaktorkan semula ke dalam fungsinya sendiri. Secara peribadi, saya sudah mempertimbangkan semula pada masa n > 3. Apa-apa yang lebih tinggi daripada itu adalah pembinaan yang meragukan dari segi kebolehbacaan.

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

Kesimpulan

Mengakhiri, kami telah melihat kes yang menarik untuk pengendali koma: operasi ternary bersyarat yang kompleks. Operator koma bersinar apabila dahannya pendek dan manis, tetapi terkeluar dari fesyen dengan cepat selepas tiga pernyataan sebaris. Pada ketika itu, seseorang mungkin lebih baik memfaktorkan semula kod.

Jadi patutkah anda menggunakan operator koma? Sejujurnya... yeah! Kod yang boleh dibaca mengambil kira pembaca seterusnya, jadi selagi rantai koma tidak pernah terlalu panjang, saya akan menerima—malah menggalakkan—gaya pengekodan ini. Jika kita mempertimbangkan alternatif (iaitu, pembolehubah tidak dimulakan dan fungsi mikro yang difaktorkan semula), pengendali koma tidaklah begitu teruk.

Dalam praktiknya, saya telah menaburkan pangkalan kod saya sendiri dengan pengendali koma yang kelihatan lucu ini. Walaupun secara adil, saya jarang sekali memerlukan syarat ternary berbilang penyata. Tetapi apabila saya melakukannya, saya mempunyai alat hebat dalam tali pinggang saya yang menyatakan niat saya dengan ringkas.

Untuk itu, saya meletakkan kes menarik saya untuk pengendali koma.

Atas ialah kandungan terperinci Kes Menarik untuk Pengendali Koma. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!