Saya akan menjadi tidak populer dan berkata Ya, ini adalah praktik yang buruk. JIKA fungsionalitas kode Anda bergantung padanya untuk menerapkan logika kondisional.
yaitu
if(quickLogicA && slowLogicB) {doSomething();}
itu bagus, tapi
if(logicA && doSomething()) {andAlsoDoSomethingElse();}
buruk, dan pasti tidak ada yang akan setuju?
if(doSomething() || somethingElseIfItFailed() && anotherThingIfEitherWorked() & andAlwaysThisThing())
{/* do nothing */}
Alasan:
Kesalahan kode Anda jika kedua belah pihak dievaluasi daripada hanya tidak melakukan logika. Telah diperdebatkan bahwa ini bukan masalah, operator 'dan' didefinisikan dalam c # jadi artinya jelas. Namun, saya berpendapat bahwa ini tidak benar.
Alasan 1. Historis
Pada dasarnya Anda mengandalkan (apa yang awalnya dimaksudkan) pengoptimalan kompiler untuk menyediakan fungsionalitas dalam kode Anda.
Meskipun dalam c # spesifikasi bahasa menjamin operator boolean 'dan' melakukan hubungan arus pendek. Ini tidak berlaku untuk semua bahasa dan kompiler.
wikipeda mencantumkan berbagai bahasa dan pendapat mereka tentang hubungan pendek http://en.wikipedia.org/wiki/Short-circuit_evaluation karena Anda dapat, ada banyak pendekatan. Dan beberapa masalah tambahan saya tidak pergi ke sini.
Secara khusus, FORTRAN, Pascal dan Delphi memiliki flag compiler yang mengubah perilaku ini.
Oleh karena itu: Anda mungkin menemukan kode Anda berfungsi ketika dikompilasi untuk rilis, tetapi tidak untuk debug atau dengan kompiler alternatif dll.
Alasan 2. Perbedaan bahasa
Seperti yang Anda lihat dari wikipedia, tidak semua bahasa menggunakan pendekatan yang sama untuk hubungan pendek, bahkan ketika mereka menentukan bagaimana operator boolean harus menanganinya.
Khususnya operator 'dan' VB.Net tidak mengalami hubungan pendek dan TSQL memiliki beberapa kekhasan.
Mengingat bahwa 'solusi' modern kemungkinan akan mencakup sejumlah bahasa, seperti javascript, regex, xpath dll. Anda harus mempertimbangkan ini saat membuat fungsi kode Anda jelas.
Alasan 3. Perbedaan dalam suatu bahasa
Misalnya inline VB jika berperilaku berbeda dari jika. Sekali lagi dalam aplikasi modern, kode Anda mungkin bergerak di antara, misalnya kode di belakang dan formulir web inline, Anda harus menyadari perbedaan makna.
Alasan 4. Contoh spesifik Anda nol memeriksa parameter fungsi
Ini adalah contoh yang sangat bagus. Dalam hal itu adalah sesuatu yang dilakukan setiap orang, tetapi sebenarnya merupakan praktik yang buruk ketika Anda memikirkannya.
Ini sangat umum untuk melihat jenis cek karena mengurangi baris kode Anda. Saya ragu ada orang yang akan membawanya dalam tinjauan kode. (dan jelas dari komentar dan penilaian Anda dapat melihatnya populer!)
Namun, itu gagal praktik terbaik karena lebih dari satu alasan!
Its sangat jelas dari berbagai sumber, bahwa praktek terbaik adalah untuk memeriksa parameter untuk validitas sebelum Anda menggunakannya dan melemparkan pengecualian jika mereka tidak valid. Cuplikan kode Anda tidak menunjukkan kode di sekitarnya, tetapi Anda mungkin harus melakukan sesuatu seperti:
if (smartphone == null)
{
//throw an exception
}
// perform functionality
Anda memanggil fungsi dari dalam pernyataan bersyarat. Meskipun nama fungsi Anda menyiratkan bahwa itu hanya menghitung nilai, itu dapat menyembunyikan efek samping. misalnya
Smartphone.GetSignal() { this.signal++; return this.signal; }
else if (smartphone.GetSignal() < 1)
{
// Do stuff
}
else if (smartphone.GetSignal() < 2)
{
// Do stuff
}
praktik terbaik akan menyarankan:
var s = smartphone.GetSignal();
if(s < 50)
{
//do something
}
Jika Anda menerapkan praktik terbaik ini ke kode Anda, Anda dapat melihat bahwa peluang Anda untuk mencapai kode yang lebih pendek melalui penggunaan kondisional tersembunyi menghilang. Praktik terbaik adalah melakukan sesuatu , untuk menangani kasus di mana ponsel cerdas adalah nol.
Saya pikir Anda akan menemukan bahwa ini juga berlaku untuk penggunaan umum lainnya. Anda harus ingat kami juga memiliki:
kondisional sebaris
var s = smartphone!=null ? smartphone.GetSignal() : 0;
dan null koalesensi
var s = smartphoneConnectionStatus ?? "No Connection";
yang menyediakan fungsionalitas panjang kode pendek serupa dengan lebih jelas
banyak tautan untuk mendukung semua poin saya:
https://stackoverflow.com/questions/1158614/what-is-the-best-practice-in-case-one-argument-is-null
Validasi parameter konstruktor dalam C # - Praktik terbaik
Haruskah seseorang memeriksa nol jika dia tidak mengharapkan nol?
https://msdn.microsoft.com/en-us/library/seyhszts%28v=vs.110%29.aspx
https://stackoverflow.com/questions/1445867/why-would-a-language-not-use-short-circuit-evaluation
http://orcharddojo.net/orchard-resources/Library/DevelopmentGuidelines/BestPractices/CSharp
contoh flag kompiler yang mempengaruhi hubungan pendek:
Fortran: "sce | nosce Secara default, kompiler melakukan evaluasi hubung singkat dalam ekspresi logis yang dipilih menggunakan aturan XL Fortran. Menentukan sce memungkinkan kompiler menggunakan aturan Fortran non-XL. Kompilator akan melakukan evaluasi hubung singkat jika aturan saat ini mengizinkannya Defaultnya adalah nosce. "
Pascal: "B - Sebuah flag directive yang mengontrol evaluasi hubung singkat. Lihat Urutan evaluasi operan operator diad untuk informasi lebih lanjut tentang evaluasi hubung singkat. Lihat juga opsi kompilator -sc untuk kompiler baris perintah untuk informasi lebih lanjut ( didokumentasikan dalam Manual Pengguna). "
Delphi: "Delphi mendukung evaluasi hubung singkat secara default. Delphi dapat dimatikan menggunakan arahan kompiler {$ BOOLEVAL OFF}."