Hancurkan case default di switch


88

Saya agak bingung kapan atau tidak untuk memasukkan breaksetelah kasus terakhir, sering default.

switch (type) {
    case 'product':

        // Do behavior

        break;
    default:

        // Do default behavior

        break; // Is it considered to be needed?
}

breakSatu-satunya tujuan adalah dalam pemahaman saya untuk menghentikan kode dari menjalankan sisa switch-kas.

Apakah kemudian dianggap lebih logis untuk memiliki yang breakterakhir karena konsistensi atau melewatkan memilikinya karena breakpenerapan tidak menggunakan fungsional apa pun? Keduanya logis dalam berbagai cara menurut saya.

Ini bisa sampai tingkat tertentu dibandingkan dengan mengakhiri .phpfile dengan ?>. Saya tidak pernah berakhir dengan ?>sebagian besar karena risiko menghasilkan ruang kosong, tetapi orang dapat berargumen bahwa akan menjadi hal yang logis untuk mengakhiri file.

Jawaban:


144

breaksecara teknis tidak diperlukan setelah alternatif terakhir (yang, ingatlah, tidak harus default: alternatifnya legal, dan kadang-kadang bahkan berguna untuk menempatkan defaultcabang terlebih dahulu); apakah kode Anda melewati akhir switchpernyataan atau breakskeluar di akhir cabang terakhir memiliki hasil yang sama.

Namun, saya masih mengakhiri setiap cabang, termasuk yang terakhir, dengan returnatau breakpernyataan, karena tiga alasan:

  1. Kemampuan reaktivitas. Jika semua cabang Anda diakhiri dengan breakatau return, Anda dapat menyusun ulangnya tanpa mengubah artinya. Ini membuatnya lebih kecil kemungkinannya untuk menyusun ulang untuk memperkenalkan regresi.
  2. Konsistensi, dan Paling Tidak Mengejutkan. Konsistensi mengatakan cabang Anda harus berakhir secara konsisten, kecuali jika keduanya benar-benar berbeda artinya. Prinsip Kejutan Paling Tidak menyatakan bahwa hal-hal yang serupa harus terlihat serupa. Mengakhiri cabang terakhir dari sebuah switchblok persis seperti yang sebelumnya memenuhi keduanya, yang membuatnya lebih mudah dibaca dan dipahami. Jika Anda meninggalkan eksplisit break, cabang terakhir akan berbeda secara optik (yang sangat penting untuk pemindaian cepat), dan untuk melihat bahwa itu benar-benar tidak berbeda, pembaca harus turun ke tingkat yang rumit dari membaca pernyataan individual .
  3. Melindungi diri Anda sendiri. Jika Anda terbiasa mengakhiri semua switchcabang Anda dengan break, itu akan menjadi otomatis setelah beberapa saat, dan Anda akan cenderung tidak sengaja melupakannya di tempat yang penting. Melatih diri Anda untuk mengharapkan breakpada akhir setiap cabang juga membantu mendeteksi breakpernyataan yang hilang , yang bagus untuk debugging dan pemecahan masalah.

Terima kasih atas wawasan Anda dalam hal ini! Akankah breakkasus terakhir juga :)
Robin Castlin

7
Dalam C #, break(atau pernyataan aliran kontrol lainnya yang keluar case) secara teknis diperlukan setelah alternatif terakhir.
dan04

3
@ dan04: ya, poin bagus. C # adalah pengecualian di sini, dan mungkin karena perancang bahasa tahu tentang masalah dengan switchfall-through dalam bahasa yang ada dan ingin mencegahnya. Aturan C # memberlakukan cukup cocok dengan rekomendasi dari jawaban saya.
Pelaku

Bahasa apa yang Anda bicarakan secara spesifik? C? C ++? C #? Jawa? PHP?
svick

2
Kompiler yang baik akan memperlakukan final breaksebagai NO-OP alih-alih menghasilkan a jmpke instruksi selanjutnya, benar?
Nathan Osman

11

Mengingat ambiguitas yang ada di sekitar penggunaan switch-casedalam sebagian besar bahasa, saat menggunakannya saya sarankan selalu menggunakan breakpernyataan, kecuali ketika itu secara eksplisit dan oleh desain tidak diinginkan .

Sebagian karena ini membuat setiap casepanggilan terlihat sama, yang menurut saya akan meningkatkan keterbacaan. Tetapi itu juga berarti jika seseorang (bahkan Anda) memilih untuk memasukkan casesetelah yang terakhir pada tahap selanjutnya, mereka tidak perlu khawatir dengan memeriksa blok sebelumnya, yang dapat membantu mengurangi bug saat menambahkan kode baru.


7
Ketika saya ingin satu kasus jatuh ke yang berikutnya (dan itu bukan kasus yang merosot dari case foo: case bar: ...), saya memberikan komentar eksplisit bahwa saya ingin jatuh-melalui terjadi. Membuatnya lebih jelas.
Donal Fellows

3
Ya seperti komentar sederhana // no breaksebagai penggantibreak;
Pacerier

Atau [[fallthrough]]atribut dalam kasus C ++.
Ruslan

1

Tidak breakperlu setelah kasus terakhir . Saya menggunakan kata " last " (tidak default ) karena tidak perlu case default adalah case terakhir.

switch(x)
{
case 1:
//do stuff
break;

default:
//do default work
break;

case 3:
//do stuff

}

Dan kita tahu, a break diperlukan antara dua cases berurutan . Terkadang, saya menggunakan if(a!=0)kode saya untuk lebih mudah dibaca ketika orang lain merujuk kode saya. Saya dapat memilih untuk menggunakan if(a), itu akan menjadi pilihan saya


5
Bagi saya itu berarti "selalu gunakan istirahat", kalau-kalau beberapa programmer menambahkan yang baru casedi akhir Anda switchtanpa memeriksa apakah breakmemang ada (itu akan menjadi kesalahan programmer, tetapi masih lebih baik aman -jika karena alasan apa pun, karena Anda bisa menjadi programmer itu dalam 6 bulan-)
SJuan76

@ SJuan76 Ya, saya setuju, lebih baik aman daripada menyesal, jika Anda ingin menjaga perlindungan untuk kesalahan di masa mendatang, Anda harus memasukkan satu di akhirnya.
Suvarna Pattayil

1
Dengan argumen itu dalam pikiran, Anda mungkin juga berdebat untuk selalu memiliki , di akhir array jika nilai baru dimasukkan. Namun itu merusak beberapa kode dan umumnya terlihat jelek :)
Robin Castlin

1
@Robin Menempatkan koma berbeda. Jika tidak ada dan seseorang menambahkan nilai baru ke array maka mereka akan mendapatkan kesalahan kompilasi. Namun tidak akan ada kesalahan kompilasi jika pernyataan kasus sebelumnya tidak ada jeda - jadi mungkin untuk ini akan terjawab dan menyebabkan kesalahan run-time.
Keith Miller

@RobinCastlin Asalkan bahasa memungkinkan Anda untuk menempatkan ,. Memetikan, defaultdirancang untuk menjadi kasus terakhir. Mungkin bahasa akan menganggap breaksetelah itu sebagai kesalahan. Dengan asumsi breakdiizinkan sebagai pembeda SAJA antara dua kasus.
Suvarna Pattayil
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.