Versi akan datang C# 14 daripada Microsoft , yang dijadualkan dikeluarkan bersama .NET 10 , memperkenalkan operator tugasan bersyarat null yang membolehkan pembangun memberikan nilai tanpa pemeriksaan null yang eksplisit. Walaupun ciri ini berjanji untuk mengurangkan kod boilerplate, ia telah mencetuskan perbincangan hangat dalam komuniti pembangun tentang sama ada ciri kemudahan sedemikian sebenarnya meningkatkan atau merosakkan kualiti kod.
Sintaks baharu ini membolehkan pembangun menulis config?.Settings.RetryPolicy = new Policy() daripada membungkus tugasan dalam pernyataan if. Ini memperluaskan operator bersyarat null sedia ada (?.) untuk berfungsi di sebelah kiri tugasan, mewujudkan konsistensi dalam pendekatan pengendalian null bahasa tersebut.
Contoh Sintaks Tugasan Null-Conditional C 14:
| Sintaks Tradisional | Sintaks Baharu C 14 |
|---|---|
if (config.Settings != null) { config.Settings.RetryPolicy = new Policy(); } |
config?.Settings.RetryPolicy = new Policy(); |
if (customerData != null) { customerData["LastLogin"] = DateTime.UtcNow; } |
customerData?["LastLogin"] = DateTime.UtcNow; |
if (results != null) { results.ItemsProcessed += 5; } |
results?.ItemsProcessed += 5; |
Had Utama:
- Operator penambahan/pengurangan (
++,--) tidak disokong - Ungkapan sebelah kanan tidak akan dinilai jika sebelah kiri adalah null
- Memerlukan .NET 10 preview SDK dan
<LangVersion>preview</LangVersion>dalam fail projek
Komuniti Berpecah Mengenai Nilai Praktikal
Pembangun mempersoalkan kegunaan dunia sebenar ciri ini. Ramai yang berhujah bahawa menghadapi nilai null semasa tugasan biasanya menunjukkan masalah reka bentuk yang perlu ditangani dan bukannya diabaikan secara senyap. Kebimbangan tertumpu pada sama ada melangkau tugasan apabila objek perantaraan adalah null sebenarnya merupakan tingkah laku yang diingini dalam kebanyakan senario.
Sesetengah pembangun menunjukkan bahawa apabila anda cuba memberikan nilai, anda biasanya mahu tugasan itu berjaya dan berterusan. Tingkah laku operator baharu yang membuang tugasan apabila nilai null ditemui mungkin menyembunyikan isu asas dalam logik aplikasi.
Kebimbangan Terhadap Kerumitan Bahasa yang Semakin Bertambah
Sebahagian besar komuniti bimbang bahawa C# mengikuti laluan C++ , mengumpul ciri-ciri yang mewujudkan beban kognitif tanpa faedah yang berkadar. Kebimbangan adalah bahawa pembangun perlu memahami set konstruk bahasa yang semakin berkembang, menjadikan pangkalan kod lebih sukar untuk diselenggara apabila pasukan berbeza menggunakan subset ciri yang tersedia yang berbeza.
Ia mula terasa seperti C# sedang mengikuti laluan C++ . Banyak ciri yang memperkenalkan kehalusan dan setiap orang mempunyai set ciri kegemaran mereka sendiri yang mereka tahu cara menggunakan.
Perbincangan ini mendedahkan kebimbangan tentang pembengkakan ciri, di mana setiap penambahan kelihatan munasabah secara berasingan tetapi secara kolektif mewujudkan bahasa yang semakin sukar untuk dikuasai secara menyeluruh.
Pertukaran Antara Kebolehbacaan dan Kebolehselenggaraan
Walaupun penyokong berhujah bahawa ciri ini mengurangkan kekusutan visual dan menjadikan kod lebih ringkas, pengkritik bimbang tentang cabaran penyahpepijatan. Sintaks baharu boleh merangkaikan berbilang tugasan bersyarat, berpotensi mewujudkan senario di mana tidak jelas mengapa nilai tidak ditetapkan. Ini boleh membawa kepada sesi penyelesaian masalah yang sukar apabila cuba menentukan bahagian mana dalam rantai bersyarat yang gagal.
Tingkah laku pencegahan kesan sampingan, di mana ungkapan sebelah kanan tidak dinilai jika sebelah kiri adalah null, menambah satu lagi lapisan kerumitan yang mesti difahami dan diingati oleh pembangun.
Implikasi yang Lebih Luas untuk Kualiti Kod
Perdebatan ini mencerminkan perbezaan falsafah yang lebih mendalam tentang reka bentuk bahasa. Sesetengah pembangun menyokong pengendalian ralat yang eksplisit dan aliran kawalan yang jelas, melihat ciri baharu sebagai menggalakkan amalan pengaturcaraan yang malas. Yang lain melihatnya sebagai evolusi semula jadi yang mengurangkan upacara dan membolehkan tumpuan pada logik perniagaan dan bukannya pengaturcaraan defensif.
Had ciri ini, seperti tidak menyokong operator kenaikan dan penurunan, menunjukkan pereka bahasa cuba mengimbangi kemudahan dengan keselamatan. Walau bagaimanapun, sekatan ini menambah model mental yang mesti dikekalkan oleh pembangun.
Perbincangan mengenai tugasan bersyarat null C# 14 akhirnya menyerlahkan ketegangan berterusan antara produktiviti pembangun dan kejelasan kod. Semasa bahasa terus berkembang, komuniti kekal berpecah sama ada ciri kemudahan sedemikian mewakili kemajuan atau kerumitan yang boleh menjejaskan kebolehselenggaraan jangka panjang.