Mengapa penggunaan kata sambung dalam nama metode merupakan konvensi penamaan yang buruk? [Tutup]


12

Di tim saya, kami bekerja erat dengan beberapa arsitek perangkat lunak. Mereka menyetujui semua keputusan desain proyek kami, melakukan beberapa tinjauan kode dll.

Proyek kami sebagian besar terdiri dari fungsi backend yang diimplementasikan dalam PHP menggunakan kerangka kerja Symfony 2. Jadi secara sintaksis, kode, konvensi penamaan dan struktur proyek terlihat hampir sama dengan apa yang akan terlihat seperti Java (Symfony 2 mendorong struktur seperti itu). Saya menyebutkan ini karena konvensi khusus Java juga berlaku dalam kasus kami (jika mungkin).

Baru-baru ini, mereka menyarankan sesuatu yang saya temukan sangat aneh: semua metode harus memiliki kata sambung dalam nama mereka misalnya getEntityOrNull, setValueOrExceptiondll.

Konvensi penamaan seperti itu terasa sangat salah bagi saya, tetapi saya tidak dapat mengemukakan argumen konkret atau artikel / halaman online yang secara khusus menentang hal ini.

Satu-satunya hal yang saya pikirkan adalah:

  • informasi tersebut harus ada dalam anotasi metode, seperti @returnatau@throws
  • penggunaan kata sambung ("dan", "atau" dll.) dalam nama metode biasanya menyarankan bahwa Prinsip Tanggung Jawab Tunggal tidak dihormati dengan benar

Apa beberapa argumen konkret lainnya yang menentang konvensi penamaan ini?



5
the use of conjunctions ("and", "or" etc.) in method names usually suggest that the Single Responsibility Principle is not properly respectedIni bukan kasus untuk contoh yang Anda daftarkan, di mana hubungannya digunakan untuk memperjelas mekanisme yang digunakan untuk menangani kegagalan, bukan untuk menunjukkan bahwa ia dapat melakukan satu atau lain hal. Bahkan fungsi yang paling sempit dapat memiliki kondisi kegagalan yang sah, misalnya memunculkan tumpukan kosong.
Doval

4
Pertimbangkan: (1) menggunakan "opsional" daripada "atau nol". "GetOptionalEntity" terdengar lebih baik di telinga saya daripada "GetEntityOrNull". (2) pustaka kelas .NET menggunakan konvensi bahwa jika Anda memiliki dua metode yang hanya berbeda dalam apa yang mereka lemparkan, beri nama yang tidak bisa membuang "TryBlah". Sebagai contoh, Int32.TryParsedan Int32.Parse- keduanya mengurai string menjadi integer, tetapi yang pertama mengembalikan Boolean yang menunjukkan keberhasilan dan yang terakhir melempar pada kegagalan.
Eric Lippert

Saya tidak akan menggunakan sufiks untuk varian melempar, tetapi saya akan menggunakan satu untuk varian null return. Bisa jadi Try..., ...OrNull, ...OrDefault. @EricLippert Itu bukan satu-satunya konvensi di .net. Pertimbangkan Singlevs. SingleOrDefault, yang sangat dekat dengan OrNullOP yang disarankan.
CodesInChaos

Jawaban:


11

Mereka mungkin melakukannya karena penamaan konflik. Saya berasumsi bahwa Anda tidak dapat memiliki dua metode bernama getEntity, satu yang mungkin melempar pengecualian dan satu lagi null. Karena itu, Anda harus memberi nama sesuai.

Pertama, saya tidak suka praktik memiliki banyak cara berbeda memanggil metode yang sama kecuali jika melakukan beberapa perubahan yang hanya dapat dilakukan oleh kelas tertentu.

Dengan kata lain, jika getValueOrNullhanya menelepon getValueOrException, menangkap pengecualian, dan dalam kasus itu kembali null, ini dapat dilakukan oleh penelepon. Ini mengacaukan kelas dengan metode yang tidak benar-benar menyumbangkan sesuatu yang bermanfaat. Sebaliknya saya lebih suka getValue, dan tahu bahwa itu melempar pengecualian. Lebih baik lagi, saya lebih suka mengetahui bahwa semua metode yang berpotensi membuang pengecualian, dan tidak ada yang kembali nullsehingga perilaku seragam di seluruh proyek saya, atau berbalikan null, semua berpotensi kembali , dan tahu bahwa penelepon harus mengeluarkan pengecualian jika yang diinginkan.

Namun, juga benar bahwa Anda tidak bertanggung jawab atas itu. Saran saya adalah untuk mengangkatnya, tetapi jangan memusingkan hal-hal kecil. Pada akhirnya, tanggung jawab dari konvensi penamaan seperti itu berada di pundak mereka, terlepas dari apakah mereka menerima saran Anda atau tidak, dan karena itu adalah penilaian mereka di telepon, saya percaya itu adalah hak prerogatif mereka untuk mengatakan tidak, menurut pendapat saya yang rendah hati.


Jika Anda harus memilih hanya satu, lebih baik untuk mengembalikan null(atau lebih baik lagi, jenis Opsional / Mungkin) karena melempar relatif mahal. Menulis pembantu yang memeriksa apakah suatu nilai tidak valid dan lemparan tidak menambah banyak overhead. Namun ketika Anda menginginkan versi tanpa-lemparan, menelan pengecualian tidak akan mengembalikan performa yang Anda ambil saat melemparnya.
Doval

1
@Doval Poin bagus, dan mungkin yang lebih penting, pengecualian harus luar biasa . Jika Anda sering melempar pengecualian, Anda tidak menggunakannya dengan benar. Satu-satunya masalah dengan pengembalian nulladalah yang nullmungkin benar-benar merupakan pengembalian yang valid dalam beberapa kasus sehingga Anda harus menyimpang dari norma dan melemparkan pengecualian dalam kasus tersebut.
Neil

3

Meskipun penggunaan konjungsi sering menunjukkan pelanggaran SRP, dalam hal ini hanya menunjukkan nilai kembali tipe data aljabar pria miskin yang bisa menjadi salah satu dari dua nilai, baik nullatau nilai "sukses".

Mereka menggunakan semacam Notasi Hongaria untuk mengkompensasi kelemahan dalam sistem tipe, yaitu kurangnya jenis yang tidak dapat dibatalkan. Dengan kata lain, tidak ada cara untuk menentukan dalam @returnanotasi Anda bahwa fungsi tidak akan pernah kembali null, dan sebaliknya, tidak ada cara untuk menentukan dalam @returnanotasi Anda bahwa fungsi tersebut dapat kembali null.

Juga, saya percaya bahwa @throwsanotasi tidak wajib dalam php, jadi tidak adanya anotasi tidak mengindikasikan tidak adanya pengecualian, meskipun itu lebih baik diselesaikan dengan membuat anotasi wajib dalam panduan gaya Anda.

Mengingat keterbatasan bahasa yang Anda gunakan, itu bukan gaya yang sepenuhnya tidak masuk akal.


2

Dalam kode saya, kadang-kadang saya membuat pasangan metode dengan nama-nama seperti getEntity () dan getEntityOrNull (). Nama tersebut membuat perilaku yang diharapkan menjadi jelas. Jika getEntity () tidak menemukan entitas maka pengecualian dilemparkan. getEntityOrNull () akan mengembalikan nol.

Dengan melakukan ini, kode panggilan menjadi sedikit lebih jelas. Jika kode panggilan harus memiliki entitas maka getEntity akan melakukan trik. Jika entitas adalah semacam hal opsional maka getEntityOrNull adalah metode pilihan.

Hal yang sama dapat diselesaikan dengan satu metode tetapi itu kemudian mengalihkan sebagian beban ke program panggilan. Anda selalu perlu menguji nol atau Anda perlu mencoba / menangkap blok. Either way itu kode tambahan yang perlu digandakan setiap kali metode ini dipanggil.

Jika arsitek Anda tidak menggunakan pasangan metode semacam ini maka ya, saya akan mempertanyakan kebutuhan untuk akhiran.

Tidak pernah benar-benar melihat metode setValueOrException. Tidak dapat memikirkan kasus penggunaan umum yang baik untuk itu.

Anda mungkin mempertimbangkan untuk bertanya kepada arsitek mengapa. Yang saya tahu selalu senang menjelaskan keputusan mereka. Seringkali dengan sangat detail (dan kadang-kadang menyiksa).


GetEntity yang akan melemparkan pengecualian pada kegagalan sama sekali tidak jelas bagi saya, saya akan mengharapkan NULL sederhana.
Elise van Looij

1

Dua argumen Anda masuk akal. Tetapi jika merekalah yang bertanggung jawab memutuskan konvensi penamaan, cobalah untuk tidak merasa terlalu buruk tentang hal itu menjadi sesuatu yang tidak Anda setujui.

Saat Anda melakukannya, Anda harus meyakinkan mereka untuk tidak menggunakan bagian "dapatkan" dan "set" kecuali metode itu benar-benar secara langsung mengatur atau mendapatkan variabel anggota.

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.