Apakah masuk akal untuk menggunakan "ys" alih-alih "ies" pada pengidentifikasi untuk memudahkan fungsi menemukan dan mengganti? [Tutup]

Meskipun secara tata bahasa salah, ketika menulis pengidentifikasi untuk fungsi, variabel dll. Apakah masuk akal untuk hanya menambahkan "s" ke bentuk jamak dari kata yang diakhiri dengan Y? Alasan saya untuk ini adalah bahwa jika Anda perlu menemukan dan mengganti, misalnya, mengganti "perusahaan" dengan "vendor", "perusahaan" akan cocok dengan bentuk tunggal dan jamak (" perusahaan dan" perusahaan "), sedangkan jika jamak dieja dengan benar, Anda harus melakukan dua pencarian terpisah.

grammar

— SHNC
sumber

Bagaimana dengan anak-anak, tikus, pisau, serigala, pria, wanita, wanita dan gigi? Semuanya valid untuk menghindari "dua pencarian terpisah" yang ditakuti .

— Tulains Córdova

Saya sendiri tidak menyukai serigala daripada serigala ...

— Jimmy Hoffa

Apakah Anda benar-benar berencana untuk mengganti nama pengidentifikasi dalam alur kerja Anda? Tampaknya agak berlebihan untuk mengambil semua keanehan kognitif dari nama yang salah eja dalam kode hanya untuk mendukung fungsi yang mungkin tidak pernah digunakan.

— Kent A.

Percayalah, Anda tidak ingin menerapkan operasi temukan dan ganti melalui basis kode besar untuk kata seperti "perusahaan" tanpa batasan "hanya kata-kata penuh". Jadi, Anda harus menggunakan dua pencarian terpisah.

— Doc Brown

Dua. Terpisah. Pencarian

— Tulains Córdova

Jawaban:

Setiap pencarian dan penggantian semacam itu harus dilakukan dengan hati-hati dan setiap perubahan diperiksa secara manual untuk misalnya menghindari "menemani" dalam komentar menjadi "acvendor" dengan perubahan perusahaan / vendor Anda. Dengan demikian, dua pencarian terpisah untuk "perusahaan" dan "perusahaan" tidak boleh menciptakan overhead yang signifikan dibandingkan dengan waktu yang dihabiskan untuk memeriksa dan menyetujui setiap perubahan.

Jadi, kata-kata yang salah eja untuk mencapai hanya satu pencarian menawarkan hal-hal negatif dari tampak buruk dan menjadi lebih sulit dibaca daripada yang seharusnya, tanpa menawarkan manfaat yang jelas.

— David Arno
sumber

Dan, dengan alat refactoring menjadi lebih baik, pencarian global dan penggantian hanya berdasarkan teks menjadi cara yang paling tidak dapat diandalkan untuk mengubah nama pengidentifikasi.

— Kent A.

Ini tidak akan menjadi masalah menggunakan pencarian "seluruh kata saja", seperti yang disebutkan oleh Doc Brown.

— SHNC

@ user3047082, seluruh pencarian kata tidak akan cocok dengan "companys", membuat seluruh pertanyaan agak tidak berguna ...

— David Arno

Saya berasumsi Anda sedang berbicara tentang penggantian nama dalam file kode sumber. Dengan IDE saat ini, ini harus selalu dilakukan dengan alat refactoring IDE. Jika IDE Anda tidak memiliki ini, pertimbangkan untuk beralih ke IDE lain. Sebagian besar alat refactoring IDE juga menyimpan riwayat refactoring, memberi Anda kemampuan untuk dengan cepat "membatalkan" jika Anda tidak menyukai hasil dari refactor. Menggunakan pencarian / ganti, Anda mungkin tidak memiliki kemampuan untuk membatalkan seluruh rangkaian perubahan (kecuali jika Anda mungkin menggunakan alat kontrol revisi dan kembali ke versi yang sebelumnya dilakukan). Selain itu, menggunakan alat refactoring Anda lebih aman dari secara tidak sengaja mengubah sesuatu yang tidak ingin Anda ubah.

— javabeano
sumber

Bagi siapa pun yang menandai jawaban ini sebagai kualitas rendah: meskipun tidak secara ketat menjawab pertanyaan seperti yang diajukan, ini membahas gambaran yang lebih besar mengapa seseorang ingin menggunakan skema penamaan seperti itu dan cara yang lebih baik untuk menyelesaikan tugas yang sama. Saya memilih "terlihat OK" untuk ulasan bendera dan menambahkan upvote.

Terima kasih, @Snowman. Sudah menjadi sifat manusia, ketika berada di area yang tidak dikenal, untuk membingkai pertanyaan berdasarkan pola pikir Anda sendiri (yang belum berpengalaman). Ya, sementara saya tidak menjawab pertanyaan yang sebenarnya, asumsi saya tentang apa yang sebenarnya ditanyakan didasarkan pada petunjuk lain dalam pertanyaan itu. Bentuk jamak yang paling banyak saya temui adalah dari alat pembuat kode, misalnya XSD-to-POJO, Hibernate / JPA reverse engineering dari database, dll. Pada dasarnya, jika bentuk jamak ini ada dalam kode dan penulis tidak menyukai pilihan bentuk jamak, maka kemungkinan besar itu tidak ditulis oleh penulis dan lebih mungkin dihasilkan secara otomatis.

— javabeano

-9

Iya! Iya! Iya! Masuk akal untuk melakukan itu. Dan saya telah melakukannya selama bertahun-tahun.

Pengungkapan 1: Bahasa Inggris bukan bahasa ibu saya.

Pengungkapan 2: Pengetahuan saya tentang tata bahasa Inggris jauh lebih baik daripada rata-rata penutur asli.

Pengungkapan 3: Ketika berbicara dengan manusia, saya adalah seorang tata bahasa Nazi yang bersemangat.

Dan sekarang setelah pengungkapan ini tidak memungkinkan, izinkan saya menyatakan bahwa tata bahasa Inggris tidak memiliki tempat dalam kode. Anda lihat, itu sebabnya ini disebut kode dan bukan prosa . Seharusnya memiliki kemiripan dengan bahasa yang dipahami oleh manusia, untuk tujuan keterbacaan, tetapi selain itu, apa yang paling kita butuhkan dari kode bukanlah kualitas prosa; itu adalah kualitas lain, lebih teknis, seperti ketepatan , ketidakjelasan , dan kesederhanaan . Itu sebabnya sintaks C dari if( x != y ) y++;adalah banyak lebih baik untuk IF X IS NOT EQUAL TO Y THEN ADD 1 TO Y END-IF.sintaks Cobol. Dugaan keinginan kompiler yang memahami bahasa alami adalah kekeliruan, dan jangan mengambil kata-kata saya untuk itu, lihat apa yang ol'Edsger katakan tentang hal itu:Edsger W. Dijkstra, Tentang kebodohan "pemrograman bahasa alami" .

Kualitas lain yang penting adalah kemampuan pengidentifikasi . Fakta bahwa properti yang dipanggil Colorselalu dapat dibaca melalui metode yang dipanggil getColor()dan ditulis melalui metode yang disebut setColor()sangat penting. Pengidentifikasi ini dapat dihitung dari nama properti, sehingga Anda tidak harus mengetahuinya dengan hati. Jika seorang programmer memilih sepasang metode yang disebut getColor()di satu sisi, tetapi colorize()di sisi lain, rekan-rekan mereka akan mempertimbangkan sabotase ini. Itulah betapa pentingnya komputabilitas pengidentifikasi.

Juga, alat pemrograman dapat ditulis (dan banyak dari mereka sebenarnya telah ditulis, misalnya, Hibernate ) yang dapat menghitung nama-nama ini. Tanpa komputabilitas nama pengidentifikasi Anda harus menggunakan sintaks tambahan (misalnya dalam Hibernate, anotasi tambahan) untuk menentukan ke setiap alat dengan tepat bagaimana membuat setiap nama pengidentifikasi tunggal, atau tepatnya nama ad hoc yang telah Anda berikan untuk setiap entitas.

Jadi, komputabilitas pengidentifikasi adalah penting, sementara pada saat yang sama tata bahasa Inggris tidak relevan, (karena kita tidak melakukan pemrograman bahasa alami,) jadi untuk dapat menghitung nama kumpulan entitas dengan selalu menambahkan "s" ke nama dari satu contoh masuk akal, apalagi fakta bahwa itu melanggar kebanyakan orang (termasuk saya) kepekaan bahasa Inggris.

Dan apakah kita suka atau tidak, ini adalah tren masa depan. Bahasa asli sebagian besar programmer di planet ini bukan bahasa Inggris lagi, dan trennya akan berlanjut dengan sangat kuat ke arah ini. (Juga, saya bahkan tidak mau bertaruh uang pada saran bahwa bahasa Inggris adalah bahasa asli dari sebagian besar programmer yang bekerja di AS sekarang.) Ini adalah orang-orang yang, sebagian besar, ketika mencoba untuk menghitung nama koleksi dari nama satu contoh "perusahaan", hanya akan menambahkan "s", dan bentuk "perusahaan" bahkan tidak akan terlintas dalam pikiran mereka. Bagi persentase programmer yang hebat dan terus meningkat di dunia, pengetahuan tentang kekhasan bahasa Inggris tidak menambah nilai pada pekerjaan mereka, itu hanya membuatnya sedikit lebih sulit.

— Mike Nakis
sumber

1. Indeks dan Indeks keduanya bentuk jamak dari indeks. Anda keliru dalam keyakinan Anda bahwa hanya satu yang benar, misalnya silakan lihat oxforddictionaries.com/definition/english/index . 2. X pribadi, yang dapat dibaca melalui getX dan ditulis melalui setX bukan pribadi; itu adalah nilai publik. 3. Kode adalah dokumen desain. Ini menginformasikan kompiler tentang cara menghasilkan "kode mesin", tetapi yang lebih penting lagi, ini menjelaskan desain itu dengan cara yang orang lain dapat dengan mudah membaca. Keterbacaan adalah salah satu dari dua aspek yang paling penting untuk dikodekan (testability menjadi yang lain).

— David Arno

Kode ditulis karena dua alasan: agar manusia membaca dan mengeksekusi komputer. Beberapa orang akan mengatakan kode sumber ditulis terutama bagi manusia untuk membaca, karena sebagian besar itu akan segera dikompilasi ke dalam kode byte sebelum komputer mengeksekusinya. Jadi, sementara komputer mungkin tidak peduli dengan tata bahasa yang tepat, manusia tentu saja melakukannya.

— Eric King

Meskipun bahasa Inggris mungkin bukan bahasa ibu Anda, mungkin orang berikutnya yang membaca kode Anda. Mungkin juga akan membingungkan orang lain dari bahasa ibu Anda yang telah belajar bahasa Inggris.

— Andy

atau Anda hanya akan melukai orang-orang yang mengambil dua kali lipat Companyssaat itu seharusnya Companies. Lagi pula, seluruh poin kode yang biasanya kita tulis sebenarnya lebih dekat dengan bahasa alami.

— Andy

Apa pun, saya menemukan kertas itu penuh dengan kotoran. Kode adalah antara bahasa alami dan bytecode. Jika tidak untuk memudahkan pemahaman manusia tentang kode, tidak akan ada alasan untuk tidak hanya memasukkan bytecode secara langsung.

— Andy