Katakanlah saya memiliki kode dalam C dengan kira-kira struktur ini:
switch (something)
{
case 0:
return "blah";
break;
case 1:
case 4:
return "foo";
break;
case 2:
case 3:
return "bar";
break;
default:
return "foobar";
break;
}
Sekarang jelas, break
s tidak diperlukan agar kode dapat berjalan dengan benar, tetapi sepertinya praktik yang buruk jika saya tidak meletakkannya di sana kepada saya.
Bagaimana menurut anda? Apakah boleh menghapusnya? Atau apakah Anda akan menyimpannya untuk meningkatkan "kebenaran"?
c
switch-statement
correctness
houbysoft
sumber
sumber
continue
ataugoto
- itu idiomatis untuk menggunakannya sebagai penggantibreak
.Saya akan mengambil taktik yang berbeda sepenuhnya. Jangan KEMBALI di tengah metode / fungsi. Sebagai gantinya, masukkan saja nilai pengembalian dalam variabel lokal dan kirimkan di akhir.
Secara pribadi, menurut saya yang berikut ini lebih mudah dibaca:
String result = ""; switch (something) { case 0: result = "blah"; break; case 1: result = "foo"; break; } return result;
sumber
Secara pribadi saya akan menghapus pengembalian dan mempertahankan istirahat. Saya akan menggunakan pernyataan switch untuk menetapkan nilai ke variabel. Kemudian kembalikan variabel itu setelah pernyataan switch.
Meskipun ini adalah poin yang bisa diperdebatkan, saya selalu merasa bahwa desain dan enkapsulasi yang baik berarti satu jalan masuk dan satu jalan keluar. Jauh lebih mudah untuk menjamin logika dan Anda tidak akan melewatkan kode pembersihan secara tidak sengaja berdasarkan kompleksitas siklus fungsi Anda.
Satu pengecualian: Mengembalikan lebih awal tidak masalah jika parameter buruk terdeteksi di awal fungsi - sebelum resource apa pun diperoleh.
sumber
switch
, tapi belum tentu yang terbaik secara umum. Nah, katakanlah pernyataan switch di dalam suatu fungsi mendahului 500 baris kode lain yang berlaku hanya ketika kasus-kasus tertentutrue
. Apa gunanya menjalankan semua kode ekstra itu untuk kasus-kasus yang tidak perlu mengeksekusinya; bukankah lebih baik hanyareturn
di dalamswitch
untukcase
itu?Pertahankan jeda - Anda cenderung tidak mengalami masalah jika / ketika Anda mengedit kode nanti jika jeda sudah ada.
Karena itu, dianggap oleh banyak orang (termasuk saya) sebagai praktik buruk untuk kembali dari tengah suatu fungsi. Idealnya sebuah fungsi harus memiliki satu titik masuk dan satu titik keluar.
sumber
Hapus mereka. Ini idiomatis untuk kembali dari
case
pernyataan, dan sebaliknya itu adalah "kode tidak terjangkau".sumber
Saya akan menghapusnya. Dalam buku saya, kode mati seperti itu harus dianggap kesalahan karena membuat Anda melakukan pengambilan ganda dan bertanya pada diri sendiri "Bagaimana saya bisa mengeksekusi baris itu?"
sumber
Saya biasanya menulis kode tanpa mereka. IMO, kode mati cenderung menunjukkan kecerobohan dan / atau kurangnya pemahaman.
Tentu saja, saya juga akan mempertimbangkan sesuatu seperti:
char const *rets[] = {"blah", "foo", "bar"}; return rets[something];
Sunting: bahkan dengan kiriman yang telah diedit, gagasan umum ini dapat bekerja dengan baik:
char const *rets[] = { "blah", "foo", "bar", "bar", "foo"}; if ((unsigned)something < 5) return rets[something] return "foobar";
Di beberapa titik, terutama jika nilai inputnya jarang (mis., 1, 100, 1000, dan 10000), Anda menginginkan array yang jarang. Anda dapat mengimplementasikannya sebagai pohon atau peta dengan cukup baik (meskipun, tentu saja, sakelar masih berfungsi dalam kasus ini juga).
sumber
Saya akan mengatakan hapus mereka dan tentukan default: branch.
sumber
Bukankah lebih baik memiliki array dengan
arr[0] = "blah" arr[1] = "foo" arr[2] = "bar"
dan lakukan
return arr[something];
?Jika ini tentang praktik secara umum, Anda harus tetap
break
mengalihkan pernyataan. Jika Anda tidak membutuhkanreturn
pernyataan di masa mendatang, hal itu mengurangi kemungkinan pernyataan tersebut gagal ke pernyataan berikutnyacase
.sumber
Untuk "kebenaran", entri tunggal, blok keluar tunggal adalah ide yang bagus. Setidaknya itulah saat saya mengambil gelar ilmu komputer. Jadi saya mungkin akan mendeklarasikan variabel, menetapkannya di sakelar dan mengembalikannya sekali di akhir fungsi
sumber
Tidak masalah untuk menghapusnya. Menggunakan
return
adalah persis skenario di manabreak
tidak boleh digunakan.sumber
Menarik. Konsensus dari sebagian besar jawaban ini tampaknya adalah bahwa
break
pernyataan yang berlebihan adalah kekacauan yang tidak perlu. Di sisi lain, saya membacabreak
pernyataan di sakelar sebagai 'penutupan' dari sebuah kasus.case
blok yang tidak berakhir denganbreak
cenderung melompat ke arah saya sebagai potensi jatuh melalui bug.Saya tahu bahwa bukan itu yang terjadi ketika ada
return
alih - alih abreak
, tetapi begitulah cara mata saya 'membaca' blok kasing di sakelar, jadi saya pribadi lebih suka masing-masingcase
dipasangkan dengan abreak
. Tetapi banyak penyusun yang mengeluh tentangbreak
setelahreturn
menjadi berlebihan / tidak dapat dijangkau, dan tampaknya saya tampaknya termasuk minoritas.Jadi singkirkan yang
break
berikut ini areturn
.NB: semua ini mengabaikan apakah melanggar aturan single entry / exit adalah ide yang bagus atau tidak. Sejauh itu, saya berpendapat bahwa sayangnya berubah tergantung pada keadaan ...
sumber
Saya katakan hapus mereka. Jika kode Anda sangat tidak terbaca sehingga Anda perlu memasukkan jeda di sana 'agar aman', Anda harus mempertimbangkan kembali gaya pengkodean Anda :)
Juga saya selalu memilih untuk tidak mencampur istirahat dan pengembalian dalam pernyataan saklar, melainkan tetap dengan salah satunya.
sumber
Saya pribadi cenderung kehilangan
break
s. Mungkin salah satu sumber kebiasaan ini adalah dari prosedur jendela pemrograman untuk aplikasi Windows:LRESULT WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) { switch (uMsg) { case WM_SIZE: return sizeHandler (...); case WM_DESTROY: return destroyHandler (...); ... } return DefWindowProc(hwnd, uMsg, wParam, lParam); }
Saya pribadi menemukan pendekatan ini jauh lebih sederhana, ringkas dan fleksibel daripada mendeklarasikan variabel pengembalian yang ditetapkan oleh masing-masing penangan, kemudian mengembalikannya di akhir. Dengan pendekatan ini,
break
s adalah redundan dan oleh karena itu harus pergi - mereka tidak melayani tujuan yang berguna (secara sintaksis atau IMO secara visual) dan hanya membengkak kode.sumber
Saya pikir * break * s ada untuk suatu tujuan. Itu untuk menjaga 'ideologi' pemrograman tetap hidup. Jika kita hanya 'memprogram' kode kita tanpa koherensi logis mungkin itu bisa dibaca oleh Anda sekarang, tapi coba besok. Cobalah menjelaskannya kepada atasan Anda. Coba jalankan di Windows 3030.
Bleah, idenya sangat sederhana:
Switch ( Algorithm ) { case 1: { Call_911; Jump; }**break**; case 2: { Call Samantha_28; Forget; }**break**; case 3: { Call it_a_day; }**break**; Return thinkAboutIt?1:return 0; void Samantha_28(int oBed) { LONG way_from_right; SHORT Forget_is_my_job; LONG JMP_is_for_assembly; LONG assembly_I_work_for_cops; BOOL allOfTheAbove; int Elligence_says_anyways_thinkAboutIt_**break**_if_we_code_like_this_we_d_be_monkeys; } // Sometimes Programming is supposed to convey the meaning and the essence of the task at hand. It is // there to serve a purpose and to keep it alive. While you are not looking, your program is doing // its thing. Do you trust it? // This is how you can... // ---------- // **Break**; Please, take a **Break**;
/ * Hanya pertanyaan kecil sekalipun. Berapa banyak kopi yang Anda miliki saat membaca penjelasan di atas? TI Terkadang merusak sistem * /
sumber
Keluar dari kode pada satu titik. Itu memberikan keterbacaan kode yang lebih baik. Menambahkan pernyataan kembali (Beberapa keluar) di antaranya akan membuat proses debug menjadi sulit.
sumber
Jika Anda memiliki jenis kode "pencarian", Anda dapat mengemas klausa switch-case dalam sebuah metode dengan sendirinya.
Saya memiliki beberapa di antaranya dalam sistem "hobi" yang saya kembangkan untuk bersenang-senang:
private int basePerCapitaIncomeRaw(int tl) { switch (tl) { case 0: return 7500; case 1: return 7800; case 2: return 8100; case 3: return 8400; case 4: return 9600; case 5: return 13000; case 6: return 19000; case 7: return 25000; case 8: return 31000; case 9: return 43000; case 10: return 67000; case 11: return 97000; default: return 130000; } }
(Ya. Itu ruang GURPS ...)
Saya setuju dengan orang lain bahwa Anda dalam banyak kasus harus menghindari lebih dari satu pengembalian dalam suatu metode, dan saya menyadari bahwa yang ini mungkin lebih baik diimplementasikan sebagai larik atau yang lain. Saya baru saja menemukan switch-case-return menjadi pertandingan yang cukup mudah untuk tabel pencarian dengan korelasi 1-1 antara input dan output, seperti hal di atas (permainan role-playing penuh dengan mereka, saya yakin mereka ada di "bisnis" juga): D
Di sisi lain, jika case-clause lebih kompleks, atau sesuatu terjadi setelah switch-statement, saya tidak akan merekomendasikan menggunakan return di dalamnya, melainkan menetapkan variabel di switch, mengakhirinya dengan jeda, dan mengembalikan nilai variabel pada akhirnya.
(Di sisi ... ketiga? Sisi ... Anda selalu dapat merefaktor sebuah saklar ke dalam metodenya sendiri ... Saya ragu ini akan berpengaruh pada kinerja, dan tidak akan mengejutkan saya jika kompiler modern bahkan dapat mengenalinya sebagai sesuatu yang bisa disisipkan ...)
sumber