Apakah ada alasan bagus mengapa lebih baik hanya memiliki satu pernyataan pengembalian dalam suatu fungsi?
Atau apakah boleh kembali dari suatu fungsi segera setelah itu secara logis benar untuk melakukannya, artinya mungkin ada banyak pernyataan pengembalian dalam fungsi?
language-agnostic
coding-style
Tim Post
sumber
sumber
Jawaban:
Saya sering memiliki beberapa pernyataan di awal metode untuk kembali untuk situasi "mudah". Sebagai contoh, ini:
... dapat dibuat lebih mudah dibaca (IMHO) seperti ini:
Jadi ya, saya pikir boleh saja memiliki beberapa "titik keluar" dari fungsi / metode.
sumber
DoStuff() { DoStuffInner(); IncreaseStuffCallCounter(); }
Tidak ada yang menyebutkan atau mengutip Kode Lengkap jadi saya akan melakukannya.
17.1 kembali
Minimalkan jumlah pengembalian di setiap rutin . Lebih sulit untuk memahami suatu rutinitas jika, jika membacanya di bagian bawah, Anda tidak menyadari kemungkinan bahwa ia kembali ke suatu tempat di atas.
Gunakan pengembalian ketika meningkatkan keterbacaan . Dalam rutinitas tertentu, setelah Anda tahu jawabannya, Anda ingin segera mengembalikannya ke rutinitas panggilan. Jika rutin didefinisikan sedemikian rupa sehingga tidak memerlukan pembersihan, tidak segera kembali berarti Anda harus menulis lebih banyak kode.
sumber
Saya akan mengatakan itu akan sangat tidak bijaksana untuk memutuskan secara sewenang-wenang terhadap beberapa titik keluar karena saya telah menemukan teknik yang berguna dalam praktek berulang kali , bahkan saya sering refactored kode yang ada ke beberapa titik keluar untuk kejelasan. Kita dapat membandingkan dua pendekatan sebagai berikut: -
Bandingkan ini dengan kode di mana beberapa exit point yang diijinkan: -
Saya pikir yang terakhir ini jauh lebih jelas. Sejauh yang saya tahu kritik beberapa titik keluar adalah sudut pandang yang agak kuno hari ini.
sumber
Saat ini saya sedang mengerjakan basis kode di mana dua orang yang mengerjakannya secara buta berlangganan teori "satu titik keluar" dan saya dapat memberitahu Anda bahwa dari pengalaman, ini adalah praktik mengerikan yang mengerikan. Itu membuat kode sangat sulit untuk dipelihara dan saya akan tunjukkan alasannya.
Dengan teori "single point of exit", Anda pasti akan berakhir dengan kode yang terlihat seperti ini:
Ini tidak hanya membuat kode sangat sulit untuk diikuti, tetapi sekarang katakan nanti Anda harus kembali dan menambahkan operasi di antara 1 dan 2. Anda harus membuat indentasi tentang seluruh fungsi panik, dan semoga sukses memastikan semua jika / kondisi lain dan kawat gigi dicocokkan dengan benar.
Metode ini membuat pemeliharaan kode sangat sulit dan rawan kesalahan.
sumber
Pemrograman terstruktur mengatakan Anda seharusnya hanya memiliki satu pernyataan pengembalian per fungsi. Ini untuk membatasi kerumitan. Banyak orang seperti Martin Fowler berpendapat bahwa lebih mudah untuk menulis fungsi dengan banyak pernyataan pengembalian. Dia menyajikan argumen ini dalam buku refactoring klasik yang ditulisnya. Ini bekerja dengan baik jika Anda mengikuti sarannya yang lain dan menulis fungsi-fungsi kecil. Saya setuju dengan sudut pandang ini dan hanya puritan pemrograman terstruktur ketat mematuhi pernyataan kembali tunggal per fungsi.
sumber
GOTO
untuk memindahkan aliran kontrol bahkan ketika fungsi ada. Itu tidak pernah mengatakan "tidak pernah menggunakanGOTO
".Seperti yang dicatat oleh Kent Beck ketika mendiskusikan klausa penjaga dalam Pola Implementasi yang membuat rutin memiliki satu pintu masuk dan keluar ...
Saya menemukan fungsi yang ditulis dengan klausa penjaga jauh lebih mudah diikuti daripada sekelompok
if then else
pernyataan panjang bersarang .sumber
Dalam fungsi yang tidak memiliki efek samping, tidak ada alasan bagus untuk memiliki lebih dari satu pengembalian dan Anda harus menuliskannya dengan gaya fungsional. Dalam metode dengan efek samping, hal-hal lebih berurutan (diindeks waktu), jadi Anda menulis dengan gaya imperatif, menggunakan pernyataan kembali sebagai perintah untuk berhenti mengeksekusi.
Dengan kata lain, jika memungkinkan, nikmatilah gaya ini
lebih dari ini
Jika Anda menemukan diri Anda menulis beberapa lapisan kondisi bersarang, mungkin ada cara Anda dapat memperbaiki itu, menggunakan daftar predikat misalnya. Jika Anda menemukan bahwa if dan elses Anda terpisah secara sintaksis, Anda mungkin ingin memecahnya menjadi fungsi yang lebih kecil. Blok bersyarat yang membentang lebih dari satu layar penuh teks sulit dibaca.
Tidak ada aturan keras dan cepat yang berlaku untuk setiap bahasa. Sesuatu seperti memiliki pernyataan pengembalian tunggal tidak akan membuat kode Anda baik. Tetapi kode yang baik akan cenderung memungkinkan Anda untuk menulis fungsi Anda seperti itu.
sumber
Saya telah melihatnya dalam standar pengkodean untuk C ++ yang merupakan hang-over dari C, seolah-olah Anda tidak memiliki RAII atau manajemen memori otomatis lainnya maka Anda harus membersihkan setiap pengembalian, yang berarti cut-and-paste dari clean-up atau goto (secara logis sama dengan 'akhirnya' dalam bahasa yang dikelola), yang keduanya dianggap sebagai bentuk yang buruk. Jika praktik Anda adalah menggunakan smart pointer dan koleksi di C ++ atau sistem memori otomatis lainnya, maka tidak ada alasan kuat untuk itu, dan itu menjadi soal keterbacaan, dan lebih dari penilaian panggilan.
sumber
auto_ptr
, Anda dapat menggunakan pointer biasa secara paralel. Meskipun akan aneh untuk menulis kode 'dioptimalkan' dengan kompiler yang tidak mengoptimalkan di tempat pertama.try
...finally
di Jawa) dan Anda perlu melakukan pemeliharaan sumber daya yang dapat Anda lakukan dengan satu kembali pada akhir suatu metode. Sebelum Anda melakukan ini, Anda harus serius mempertimbangkan refactoring kode untuk menyingkirkan situasi.Saya bersandar pada gagasan bahwa pernyataan pengembalian di tengah fungsi itu buruk. Anda dapat menggunakan pengembalian untuk membangun beberapa klausa penjaga di bagian atas fungsi, dan tentu saja memberi tahu kompiler apa yang harus kembali di akhir fungsi tanpa masalah, tetapi pengembalian di tengah fungsi bisa mudah dilewatkan dan dapat membuat fungsi lebih sulit untuk ditafsirkan.
sumber
Ya ada:
Pertanyaan itu sering diajukan sebagai dikotomi palsu antara pengembalian berganda atau pernyataan if. Hampir selalu ada solusi ketiga yang sangat linier (tidak ada sarang dalam) dengan hanya satu titik keluar.
Pembaruan : Rupanya pedoman MISRA juga mempromosikan jalan keluar tunggal .
Untuk lebih jelasnya, saya tidak mengatakan itu selalu salah untuk memiliki beberapa pengembalian. Tetapi dengan memberikan solusi yang setara, ada banyak alasan bagus untuk memilih yang dengan pengembalian tunggal.
sumber
Contract.Ensures
dengan beberapa titik pengembalian.goto
untuk mendapatkan kode pembersihan umum, maka Anda mungkin telah menyederhanakan fungsi sehingga ada satureturn
di akhir kode pembersihan. Jadi Anda bisa mengatakan Anda telah menyelesaikan masalah dengangoto
, tetapi saya akan mengatakan Anda menyelesaikannya dengan menyederhanakan menjadi satureturn
.Memiliki satu titik keluar memang memberikan keuntungan dalam debugging, karena memungkinkan Anda untuk menetapkan breakpoint tunggal di akhir fungsi untuk melihat nilai apa yang sebenarnya akan dikembalikan.
sumber
Secara umum saya mencoba untuk hanya memiliki satu titik keluar dari suatu fungsi. Namun, ada kalanya melakukan hal itu pada akhirnya menciptakan fungsi tubuh yang lebih kompleks daripada yang diperlukan, dalam hal ini lebih baik memiliki beberapa titik keluar. Itu benar-benar harus menjadi "panggilan penilaian" berdasarkan kompleksitas yang dihasilkan, tetapi tujuannya harus sesedikit mungkin titik keluar tanpa mengorbankan kompleksitas dan pemahaman.
sumber
Tidak, karena kita tidak hidup di tahun 1970-an lagi . Jika fungsi Anda cukup lama sehingga banyak pengembalian merupakan masalah, itu terlalu lama.
(Terlepas dari kenyataan bahwa setiap fungsi multi-line dalam bahasa dengan pengecualian akan memiliki beberapa titik keluar.)
sumber
Preferensi saya adalah keluar satu kali kecuali itu benar-benar menyulitkan. Saya telah menemukan bahwa dalam beberapa kasus, beberapa titik yang ada dapat menutupi masalah desain lain yang lebih signifikan:
Saat melihat kode ini, saya akan segera bertanya:
Tergantung pada jawaban atas pertanyaan-pertanyaan ini, mungkin itu
Dalam kedua kasus di atas kode mungkin dapat dikerjakan ulang dengan pernyataan untuk memastikan bahwa 'foo' tidak pernah nol dan penelepon yang relevan berubah.
Ada dua alasan lain (khusus saya pikir untuk kode C ++) di mana ada beberapa sebenarnya dapat memiliki pengaruh negatif . Mereka adalah ukuran kode, dan optimisasi kompiler.
Objek non-POD C ++ dalam lingkup pada saat keluar dari suatu fungsi akan memanggil destruktornya. Di mana ada beberapa pernyataan pengembalian, mungkin ada kasus bahwa ada objek yang berbeda dalam ruang lingkup dan daftar destruktor untuk memanggil akan berbeda. Oleh karena itu kompiler perlu membuat kode untuk setiap pernyataan kembali:
Jika ukuran kode merupakan masalah - maka ini mungkin sesuatu yang layak dihindari.
Masalah lainnya berkaitan dengan "Optimalisasi Nilai Pengembalian Bernama" (alias Copy Elision, ISO C ++ '03 12.8 / 15). C ++ memungkinkan implementasi untuk melewati pemanggilan copy constructor jika dapat:
Hanya dengan mengambil kode apa adanya, objek 'a1' dikonstruksikan dalam 'foo' dan kemudian salinan konstruksinya akan dipanggil untuk membangun 'a2'. Namun, copy elision memungkinkan kompiler untuk membangun 'a1' di tempat yang sama pada stack sebagai 'a2'. Karena itu tidak perlu "menyalin" objek ketika fungsi kembali.
Beberapa titik keluar mempersulit pekerjaan kompiler dalam mencoba mendeteksi ini, dan setidaknya untuk versi VC ++ yang relatif baru, optimasi tidak terjadi di mana fungsi tubuh memiliki beberapa pengembalian. Lihat Optimasi Nilai Pengembalian Bernama dalam Visual C ++ 2005 untuk detail lebih lanjut.
sumber
throw new ArgumentNullException()
dalam C # dalam kasus ini), saya benar-benar menyukai pertimbangan Anda yang lain, mereka semua valid untuk saya, dan bisa kritis dalam beberapa konteks niche.foo
sedang diuji tidak ada hubungannya dengan subjek, yaitu apakah harus melakukanif (foo == NULL) return; dowork;
atauif (foo != NULL) { dowork; }
Memiliki satu titik keluar mengurangi Kompleksitas Siklomatik dan oleh karena itu, secara teori , mengurangi kemungkinan Anda akan memasukkan bug ke dalam kode Anda ketika Anda mengubahnya. Namun praktiknya, cenderung menunjukkan bahwa pendekatan yang lebih pragmatis diperlukan. Karena itu saya cenderung bertujuan untuk memiliki satu titik keluar, tetapi mengizinkan kode saya untuk memiliki beberapa jika itu lebih mudah dibaca.
sumber
Saya memaksakan diri untuk menggunakan hanya satu
return
pernyataan, karena akan menghasilkan kode bau. Biarkan saya jelaskan:(Kondisinya arbriter ...)
Semakin banyak kondisi, semakin besar fungsinya, semakin sulit untuk dibaca. Jadi jika Anda terbiasa dengan bau kode, Anda akan menyadarinya, dan ingin memperbaiki kode tersebut. Dua solusi yang mungkin adalah:
Pengembalian Berganda
Fungsi yang terpisah
Memang, ini lebih panjang dan sedikit berantakan, tetapi dalam proses refactoring fungsi dengan cara ini, kami sudah
sumber
Saya akan mengatakan Anda harus memiliki sebanyak yang diperlukan, atau yang membuat kode lebih bersih (seperti klausa penjaga ).
Saya pribadi tidak pernah mendengar / melihat "praktik terbaik" yang mengatakan bahwa Anda hanya boleh memiliki satu pernyataan pengembalian.
Untuk sebagian besar, saya cenderung untuk keluar dari fungsi sesegera mungkin berdasarkan jalur logika (klausa penjaga adalah contoh yang sangat baik dari ini).
sumber
Saya percaya bahwa banyak pengembalian biasanya baik (dalam kode yang saya tulis dalam C #). Gaya pengembalian tunggal adalah peninggalan dari C. Tapi Anda mungkin tidak mengkodekan dalam C.
Tidak ada hukum yang mewajibkan hanya satu titik keluar untuk metode dalam semua bahasa pemrograman . Beberapa orang bersikeras pada keunggulan gaya ini, dan kadang-kadang mereka mengangkatnya ke "aturan" atau "hukum" tetapi kepercayaan ini tidak didukung oleh bukti atau penelitian.
Lebih dari satu gaya pengembalian mungkin kebiasaan buruk dalam kode C, di mana sumber daya harus secara eksplisit dialokasikan, tetapi bahasa seperti Java, C #, Python atau JavaScript yang memiliki konstruksi seperti pengumpulan dan
try..finally
blok sampah otomatis (danusing
blok dalam C # ), dan argumen ini tidak berlaku - dalam bahasa-bahasa ini, sangat jarang membutuhkan alokasi sumber daya manual yang terpusat.Ada kasus di mana pengembalian tunggal lebih mudah dibaca, dan kasus di mana tidak kembali. Lihat apakah itu mengurangi jumlah baris kode, membuat logika lebih jelas atau mengurangi jumlah kawat gigi dan inden atau variabel sementara.
Karena itu, gunakan pengembalian sebanyak mungkin sesuai dengan kepekaan artistik Anda, karena ini adalah masalah tata letak dan keterbacaan, bukan masalah teknis.
Saya telah membicarakan hal ini lebih jauh di blog saya .
sumber
Ada hal-hal baik untuk dikatakan tentang memiliki satu titik keluar, sama seperti ada hal-hal buruk untuk dikatakan tentang pemrograman "panah" yang tak terhindarkan yang dihasilkan.
Jika menggunakan beberapa titik keluar selama validasi input atau alokasi sumber daya, saya mencoba menempatkan semua 'kesalahan-keluar' dengan sangat jelas di bagian atas fungsi.
Baik artikel Pemrograman Spartan dari "SSDSLPedia" dan artikel titik keluar fungsi tunggal dari "Portland Pattern Repository's Wiki" memiliki beberapa argumen mendalam tentang hal ini. Juga, tentu saja, ada posting ini untuk dipertimbangkan.
Jika Anda benar-benar ingin satu titik keluar (dalam bahasa apa pun yang tidak diaktifkan) sebagai contoh untuk melepaskan sumber daya di satu tempat, saya menemukan aplikasi goto yang cermat menjadi baik; lihat misalnya ini contoh yang agak dibuat-buat (dikompresi untuk menyimpan layar real-estate):
Secara pribadi saya, secara umum, tidak suka pemrograman panah lebih dari saya tidak suka beberapa titik keluar, meskipun keduanya berguna ketika diterapkan dengan benar. Yang terbaik, tentu saja, adalah menyusun program Anda untuk tidak membutuhkan keduanya. Memecah fungsi Anda menjadi beberapa bagian biasanya membantu :)
Meskipun ketika melakukan itu, saya menemukan saya akhirnya memiliki beberapa titik keluar seperti dalam contoh ini, di mana beberapa fungsi yang lebih besar telah dipecah menjadi beberapa fungsi yang lebih kecil:
Bergantung pada proyek atau pedoman pengkodean, sebagian besar kode pelat-ketel dapat diganti dengan makro. Sebagai catatan, memecahnya dengan cara ini membuat fungsi g0, g1, g2 sangat mudah untuk diuji secara individual.
Jelas, dalam bahasa OO dan bahasa yang diaktifkan pengecualian, saya tidak akan menggunakan pernyataan if seperti itu (atau sama sekali, jika saya bisa lolos dengan sedikit usaha), dan kodenya akan jauh lebih sederhana. Dan tidak panah. Dan sebagian besar pengembalian non-final mungkin akan menjadi pengecualian.
Pendeknya;
sumber
Anda tahu pepatah - keindahan ada di mata yang melihatnya .
Beberapa orang bersumpah oleh NetBeans dan beberapa oleh IntelliJ IDEA , beberapa oleh Python dan beberapa oleh PHP .
Di beberapa toko Anda bisa kehilangan pekerjaan jika Anda bersikeras melakukan ini:
Pertanyaannya adalah semua tentang visibilitas dan pemeliharaan.
Saya kecanduan menggunakan aljabar boolean untuk mengurangi dan menyederhanakan logika dan penggunaan mesin negara. Namun, ada kolega masa lalu yang percaya bahwa mempekerjakan saya "teknik matematika" dalam pengkodean tidak cocok, karena itu tidak akan terlihat dan dipelihara. Dan itu akan menjadi praktik yang buruk. Maaf orang-orang, teknik yang saya terapkan sangat terlihat dan dapat dipelihara untuk saya - karena ketika saya kembali ke kode enam bulan kemudian, saya akan memahami kode dengan jelas daripada melihat kekacauan spaghetti pepatah.
Hai teman (seperti mantan klien sebelumnya) lakukan apa yang Anda inginkan selama Anda tahu cara memperbaikinya ketika saya membutuhkan Anda untuk memperbaikinya.
Saya ingat 20 tahun yang lalu, seorang rekan saya dipecat karena menggunakan apa yang hari ini disebut strategi pengembangan yang gesit . Dia punya rencana tambahan yang cermat. Tetapi manajernya meneriakinya, "Anda tidak dapat secara bertahap merilis fitur kepada pengguna! Anda harus tetap menggunakan air terjun ." Tanggapannya kepada manajer adalah bahwa pengembangan tambahan akan lebih tepat untuk kebutuhan pelanggan. Dia percaya dalam mengembangkan untuk kebutuhan pelanggan, tetapi manajer percaya pada pengkodean untuk "kebutuhan pelanggan".
Kami sering bersalah karena melanggar normalisasi data, batas MVP dan MVC . Kami sebaris bukannya membangun fungsi. Kami mengambil jalan pintas.
Secara pribadi, saya percaya bahwa PHP adalah praktik yang buruk, tetapi apa yang saya tahu. Semua argumen teoretis bermuara pada upaya memenuhi satu set aturan
Semua aturan lain menghilang ke latar belakang. Dan tentu saja aturan ini tidak pernah pudar:
sumber
Saya condong ke arah menggunakan klausa penjaga untuk kembali lebih awal dan sebaliknya keluar pada akhir metode. Aturan masuk dan keluar tunggal memiliki signifikansi historis dan sangat membantu ketika berhadapan dengan kode lawas yang berlari ke 10 halaman A4 untuk metode C ++ tunggal dengan banyak pengembalian (dan banyak cacat). Baru-baru ini, praktik baik yang diterima adalah menjaga metode tetap kecil yang membuat banyak jalan keluar lebih sedikit dari hambatan untuk memahami. Dalam contoh Kronoz berikut yang disalin dari atas, pertanyaannya adalah apa yang terjadi pada // Sisa kode ... ?:
Saya menyadari bahwa contohnya agak dibuat-buat tetapi saya akan tergoda untuk mengubah loop foreach menjadi pernyataan LINQ yang kemudian dapat dianggap sebagai klausa penjaga. Sekali lagi, dalam contoh buat maksud dari kode ini tidak jelas dan someFunction () mungkin memiliki beberapa efek samping lain atau hasilnya dapat digunakan dalam // Istirahat kode ... .
Memberi fungsi refactored berikut:
sumber
null
bukannya melemparkan pengecualian yang menunjukkan bahwa argumen tersebut tidak diterima?Satu alasan bagus yang dapat saya pikirkan adalah untuk pemeliharaan kode: Anda memiliki satu titik keluar. Jika Anda ingin mengubah format hasil, ..., itu hanya jauh lebih mudah untuk diterapkan. Juga, untuk debugging, Anda bisa menempel breakpoint di sana :)
Karena itu, saya pernah harus bekerja di perpustakaan di mana standar pengkodean memberlakukan 'satu pernyataan pengembalian per fungsi', dan saya merasa cukup sulit. Saya menulis banyak kode perhitungan numerik, dan sering kali ada 'kasus khusus', sehingga kode tersebut menjadi cukup sulit untuk diikuti ...
sumber
Beberapa titik keluar baik untuk fungsi yang cukup kecil - yaitu, fungsi yang dapat dilihat pada satu layar secara keseluruhan. Jika fungsi yang panjang juga mencakup beberapa titik keluar, itu menandakan bahwa fungsi tersebut dapat dicincang lebih lanjut.
Yang mengatakan saya menghindari beberapa fungsi keluar kecuali benar-benar diperlukan . Saya telah merasakan sakit bug yang disebabkan oleh beberapa penyimpangan dalam garis yang tidak jelas dalam fungsi yang lebih kompleks.
sumber
Saya telah bekerja dengan standar pengkodean yang mengerikan yang memaksa satu jalur keluar pada Anda dan hasilnya hampir selalu spaghetti tidak terstruktur jika fungsinya sama sekali tidak sepele - Anda berakhir dengan banyak jeda dan terus yang hanya menghalangi.
sumber
if
pernyataan di depan setiap panggilan metode yang mengembalikan kesuksesan atau tidak :(Satu titik keluar - semuanya setara - membuat kode lebih mudah dibaca. Tapi ada yang menarik: konstruksi populer
adalah palsu, "res =" tidak jauh lebih baik daripada "kembali". Ini memiliki pernyataan pengembalian tunggal, tetapi beberapa titik di mana fungsi sebenarnya berakhir.
Jika Anda memiliki fungsi dengan banyak pengembalian (atau "res =" s), seringkali merupakan ide bagus untuk memecahnya menjadi beberapa fungsi yang lebih kecil dengan titik keluar tunggal.
sumber
Kebijakan saya yang biasa adalah hanya memiliki satu pernyataan kembali di akhir fungsi kecuali kompleksitas kode sangat berkurang dengan menambahkan lebih banyak. Sebenarnya, saya lebih suka penggemar Eiffel, yang memberlakukan satu-satunya aturan pengembalian dengan tidak memiliki pernyataan pengembalian (hanya ada variabel 'hasil' yang dibuat secara otomatis untuk memasukkan hasil Anda).
Tentu saja ada kasus-kasus di mana kode dapat dibuat lebih jelas dengan beberapa pengembalian daripada versi yang jelas tanpa mereka. Orang bisa berpendapat bahwa diperlukan lebih banyak pengerjaan ulang jika Anda memiliki fungsi yang terlalu rumit untuk dapat dipahami tanpa banyak pernyataan pengembalian, tetapi kadang-kadang ada baiknya bersikap pragmatis tentang hal-hal seperti itu.
sumber
Jika Anda berakhir dengan lebih dari beberapa pengembalian mungkin ada sesuatu yang salah dengan kode Anda. Kalau tidak, saya akan setuju bahwa kadang-kadang senang bisa kembali dari beberapa tempat dalam subrutin, terutama ketika itu membuat kode lebih bersih.
Perl 6: Contoh Buruk
akan lebih baik ditulis seperti ini
Perl 6: Contoh Baik
Perhatikan ini hanyalah contoh cepat
sumber
Saya memilih Single return di akhir sebagai pedoman. Ini membantu penanganan pembersihan kode umum ... Misalnya, lihat kode berikut ...
sumber
Ini mungkin perspektif yang tidak biasa, tetapi saya pikir siapa pun yang percaya bahwa pernyataan pengembalian berganda lebih disukai tidak pernah harus menggunakan debugger pada mikroprosesor yang hanya mendukung 4 breakpoint perangkat keras. ;-)
Sementara masalah "kode panah" sepenuhnya benar, satu masalah yang tampaknya hilang ketika menggunakan beberapa pernyataan kembali adalah dalam situasi di mana Anda menggunakan debugger. Anda tidak memiliki posisi tangkap semua yang nyaman untuk meletakkan breakpoint untuk menjamin bahwa Anda akan melihat pintu keluar dan karenanya kondisi pengembalian.
sumber
Semakin banyak pernyataan pengembalian yang Anda miliki dalam suatu fungsi, semakin tinggi kompleksitas dalam satu metode itu. Jika Anda bertanya-tanya apakah Anda memiliki terlalu banyak pernyataan pengembalian, Anda mungkin ingin bertanya pada diri sendiri apakah Anda memiliki terlalu banyak baris kode dalam fungsi itu.
Tapi, tidak, tidak ada yang salah dengan satu / banyak pernyataan pengembalian. Dalam beberapa bahasa, ini adalah praktik yang lebih baik (C ++) daripada yang lain (C).
sumber