Kata kunci tidak sensitif huruf besar-kecil dalam suatu bahasa [ditutup]

Kami mencoba menulis bahasa skrip khusus. Ada saran untuk membuat bahasa pemaaf dengan memberikan kata kunci yang tidak sensitif .

Saya pribadi tidak suka ide itu, tetapi ada beberapa orang di tim saya yang condong ke sana, mengatakan itu akan membuat pengguna akhir senang! Contoh bahasa seperti FORTRAN, BASIC, SQL diberikan dengan mengatakan bahwa ini adalah case-sensitive.

Apakah ini ide yang bagus?

Tanyakan pada diri sendiri siapa pengguna akhir. Jika itu dimaksudkan untuk ditulis oleh seseorang dengan pengalaman pemrograman dalam C atau Javscript, atau pengalaman IT di Unix, maka sensitivitas case mungkin adalah hal yang benar untuk dilakukan, karena itulah yang diharapkan pengguna. Tetapi untuk sebagian besar pengguna akhir, bahkan pengguna daya, ini akan membingungkan.

VB / VBA / VBScript tidak peka huruf besar-kecil, dan ini adalah keputusan yang dibuat untuk memungkinkan non-programmer dengan mudah memahami bahasa tersebut. Rumus Excel, bukan skrip persis tetapi sedekat yang didapat banyak pengguna, tidak peka huruf besar-kecil. Dalam kebanyakan penulisan pilihan case dapat membuat teks terlihat lebih atau kurang profesional dan dipoles, tetapi case itu sendiri tidak akan mengubah makna semantik dari kata-kata. Itu sebabnya saya percaya non-pengembang akan bingung oleh bahasa scripting yang sensitif.

Sekali lagi, ini bukan pilihan teknis. Ini adalah pilihan manajemen produk yang harus dibuat oleh orang-orang yang mengenal target audiens dengan baik.

Anda harus memutuskan berdasarkan pengalaman pengguna yang ingin Anda presentasikan, bukan seberapa mudah atau sulit untuk mengimplementasikannya.

Jika itu akan membuat lebih mudah bagi pengguna Anda untuk memiliki ketidakpekaan huruf maka itulah yang harus Anda terapkan.

Sebagai kasus di titik SQL adalah case-sensitive. Ini membuatnya sangat mudah digunakan dalam pengaturan interaktif.

Cara lain untuk melihat ini adalah apakah akan ada perbedaan antara keyworddan Keyworddalam bahasa Anda, dan apakah perbedaan ini akan berarti bagi pengguna? Untuk bahasa scripting saya katakan jawabannya "tidak".

Bahasa pemrograman harus case-sensitive, titik. Orang-orang dapat menyesuaikan diri dengan ini dengan mudah: mereka hanya harus ingat untuk bekerja sebagian besar dalam huruf kecil, dan harus waspada terhadap pengidentifikasi huruf besar atau huruf besar semua di API yang ada.

Dulu tampak jelas membuat bahasa tidak peka huruf besar-kecil. Ini karena huruf kecil tidak tersedia pada semua sistem komputasi dan perangkat I / O mereka (keyboard, printer, dan perangkat tampilan). Pemrograman implementasi bahasa harus menerima program yang ditulis dalam huruf besar, karena hanya itu yang dapat ditampilkan atau dicetak. Dan untuk itu mereka harus peka terhadap huruf besar-kecil, karena menerima huruf besar dan peka huruf besar-kecil berarti menolak huruf kecil. Huruf kecil adalah sesuatu yang diinginkan programmer, tetapi tidak selalu bisa. Tidak ada yang benar-benar ingin bekerja dengan program yang berteriak dalam huruf besar; itu hanya batasan perangkat keras.

Untuk sementara, adalah hal yang umum untuk bahkan melakukan pelipatan case di terminal. Jika terminal hanya dapat menampilkan huruf besar, tetapi Anda harus masuk ke sistem komputasi yang mendukung huruf besar dan kecil, terminal akan melipat huruf kecil ke huruf besar. Pikir ini sudah lama sekali? "Seperti Apple II, Apple II Plus tidak memiliki fungsi huruf kecil." (http://en.wikipedia.org/wiki/Apple_II_Plus) Ketika pengguna komputer Apple awal melakukan panggilan ke BBS yang memiliki konten campuran, emulator terminal (atau host) harus melipat semuanya ke huruf besar. Pesan yang ditulis dalam semua huruf adalah hal biasa di papan buletin pada masa itu. Fungsi ini masih ditemukan di sistem operasi mirip Unix, seperti kernel Linux. Misalnya, ketikstty olcuc prompt shell Anda.Disiplin garis tty Unix dapat memetakan huruf kecil ke atas pada output, dan itu dapat memetakan huruf besar untuk lebih rendah pada input. Ini memungkinkan Anda untuk bekerja dalam bahasa pemrograman huruf kecil, pada terminal yang tidak memiliki huruf kecil.

Ketidakpekaan case adalah konsep yang ketinggalan jaman dari era komputer masa lalu yang tidak berfungsi dengan baik di dunia modern dari komputasi internasional. Apakah Anda memperluas itu ke bahasa lain? Bagaimana dengan bahasa Prancis: apakah Anda menganggap È dan è setara? Atau Jepang? Apakah Anda menganggap hiragana dan katakana hanya sebagai kasus, sehingga フ ァ イ ル dan ふ ぁ い る adalah pengidentifikasi yang sama? Dukungan untuk kebodohan semacam itu akan sangat menyulitkan penganalisa leksikal Anda, yang harus memiliki peta kesetaraan kasus untuk seluruh ruang Unicode.

Perhatikan bahwa matematika peka terhadap huruf besar-kecil. Misalnya, sigma huruf besar mungkin menunjukkan penjumlahan, sedangkan sigma huruf kecil menunjukkan sesuatu yang lain, seperti standar deviasi. Ini dapat terjadi dalam formula yang sama tanpa membuat kesulitan. (Apakah bahasa pemrograman akan membuat Σ dan σ setara?)

Ortografi bahasa Inggris sensitif. Misalnya, banyak kata benda yang sesuai dengan kata benda biasa atau bahkan bagian lain dari pembicaraan. "mungkin" adalah kata kerja, tetapi "Mei" adalah satu bulan, atau nama wanita. Selain itu, jika akronim atau singkatan ditulis dalam huruf kecil, itu bisa membingungkan. SAT adalah singkatan dari tes bakat skolastik, sedangkan "sat" adalah partisip masa lalu dari "sat". Orang cerdas memperhatikan detail dan memanfaatkan dengan baik.

Pada dasarnya, bahasa pemrograman baru apa pun yang dibuat sejak 1985 yang tidak peka terhadap huruf besar adalah UNTUK MEREKA YANG MASIH HARUS DI E-MAILS DAN POSING TANPA PIKIRAN KEDUA.

Bagaimana jika bahasa Anda pernah digunakan sebagai target pembuatan kode untuk menerjemahkan kode dalam bahasa lain, dan bahasa lain itu peka terhadap huruf besar-kecil? Anda harus entah bagaimana mengubah semua nama untuk menangkap perbedaannya. (Jadi untuk menegaskan bahwa ini bukan keputusan teknis, dan hanya masalah preferensi emosional dari audiens target, konyol.)

Lihatlah masalah menjengkelkan yang disebabkan oleh penanganan kasus di Windows, saat file diimpor dari sistem operasi lain. Itu masalah teknis. Sistem file case sensitif memiliki masalah dengan data asing yang tidak case-sensitive.

Lisp umum telah mencapai pendekatan yang ideal: nama simbol peka huruf besar-kecil, tetapi ketika token dibaca, mereka dilipat ke huruf besar. Ini berarti bahwa token foo, fOO, FOOdan Foosemua menyatakan simbol yang sama: simbol yang namanya disimpan sebagai string karakter "FOO". Selanjutnya, perilaku ini hanya konfigurasi tabel baca default. Pembaca dapat melipat huruf ke huruf besar, huruf kecil, membalikkan huruf, atau menyimpannya. Dua pilihan terakhir memunculkan dialek yang peka terhadap huruf besar-kecil. Dengan cara ini, pengguna memiliki fleksibilitas maksimum.

Faktor penentu nyata adalah seberapa sering Anda ingin memiliki banyak hal dengan nama yang sama. Ketidaksensitifan huruf berfungsi di SQL karena tidak sering Anda menginginkan kolom bernama SELECT. Ini akan menjengkelkan di Jawa karena setiap baris lainnya terlihat seperti Object object = new Object(), di mana Anda ingin nama yang sama merujuk ke kelas, contoh, dan konstruktor.

Dengan kata lain, sensitivitas huruf sebagian besar berguna untuk overloading nama, dan overloading sebagian besar berguna dalam proyek-proyek besar dan kompleks. Untuk penggunaan yang lebih jarang, seperti bahasa scripting, ketidakpekaan huruf dapat membuat pemrograman lebih sederhana.

Saya pernah membuat bahasa aturan di mana pengidentifikasi tidak hanya peka huruf besar kecil, mereka juga tidak berwarna putih. Saya juga mengizinkan membuat alias yang merujuk ke pengidentifikasi yang sama. Sebagai contoh, ProgrammersStackExchange, pertukaran programmer programmer, dan PSE semua diselesaikan dengan simbol yang sama persis dan dapat digunakan secara bergantian.

Untuk domain saya yang bekerja sangat baik, karena domain tersebut memiliki banyak cara yang sangat terkenal untuk merujuk hal yang sama, dan konflik penamaan jarang terjadi. Tidak ada yang akan terkejut dengan mengetik kueri menggunakan satu nama dan hasilnya hasilnya menggunakan yang lain. Memiliki dukungan bahasa membuat penerjemahan antara domain dan bahasa pemrograman menjadi sangat mudah. Namun, itu juga membuat tugas-tugas tertentu lebih sulit, seperti menemukan semua referensi ke variabel. Untungnya, dalam kasus saya situasi semacam itu jarang muncul, atau cukup mudah untuk membangun dukungan alat untuk membantu, tetapi Anda harus mempertimbangkan situasi Anda sendiri.

Diasumsikan bahasa skrip Anda akan menjadi case-sensitive - apakah Anda akan membuat kompiler atau pemeriksa sintaks yang akan memberi tahu pengguna jika ia membuat kesalahan ketik dengan menggunakan case yang salah dalam nama variabel atau kata kunci? Jika tidak, itu akan menjadi argumen yang sangat kuat untuk membuat kasus bahasa tidak peka.

Bisakah Anda mendeklarasikan variabel saat itu juga? Jika demikian saya akan berdebat melawan case sensitif, seperti melacak bug yang disebabkan oleh

ATypo = 42; 

sebagai lawan

Atypo = 42; 

tidak perlu meminta waktu debug, ketika memiliki dua pernyataan yang setara hanya membuat hidup lebih mudah.

Contoh bahasa seperti FORTRAN, BASIC, SQL diberikan dengan mengatakan bahwa ini adalah case-sensitive.

Alasan mengapa FORTRAN dan SQL (dan COBOL) tidak sensitif huruf adalah karena mereka awalnya dirancang untuk digunakan pada mesin di mana set karakter normal hanya memiliki huruf besar. Ketidaksensitifan kasus dalam bahasa-bahasa tersebut (setidaknya) lebih merupakan artefak historis daripada pilihan desain bahasa.

Sekarang Anda dapat berargumen bahwa ketidakpekaan case lebih memaafkan, tetapi sisi sebaliknya adalah bahwa sensitivitas case menghasilkan kode yang lebih mudah dibaca karena ia mendapatkan lebih dari satu hal.

Sensitivitas kasus dianggap berbahaya.

Hidup tidak peka huruf besar kecil dan juga bukan pengguna atau pemrogram.

Bahasa yang peka terhadap huruf besar-kecil adalah kecelakaan historis, dari sistem terbatas yang menganggap sulit membandingkan perbandingan kasus dengan huruf besar-kecil. Cacat ini tidak ada lagi, jadi tidak ada alasan untuk membuat sistem komputer yang peka terhadap huruf besar lagi.

Saya akan mengatakan bahwa sensitivitas huruf adalah jahat , karena menempatkan kenyamanan komputer di atas kenyamanan pengguna.

(Terkait, saya ingat beberapa tahun yang lalu, beberapa jenius menolak untuk membayar tagihan kartu kreditnya karena namanya tertulis dalam huruf besar semua, tetapi ia mengeja hurufnya campuran. Oleh karena itu, ia berpendapat, itu tidak ditujukan dengan baik kepadanya dan tidak permintaan pembayaran yang sah. Hakim memperlakukan argumen sebagaimana layaknya).

Dari pengalaman pribadi saya, saya tidak melihat perbedaan besar antara bahasa yang peka terhadap huruf besar dan kecil.

Yang lebih penting adalah penamaan dan konvensi struktural yang harus disimpan oleh seorang programmer dalam kodenya dan tidak ada kompiler atau parser yang memeriksanya. Jika Anda tetap berpegang pada beberapa jenis aturan, Anda akan dengan mudah mengetahui nama yang tepat (Anda tidak akan berpikir jika Anda menamai variabel CheckOut atau CheckOut) dan kode Anda mungkin peka huruf besar-kecil dan lebih mudah dibaca.

Seseorang seharusnya tidak menggunakan CheckOut dan checkOut dan checkout dan cHeCkOuT dan CHECKOUT dalam arti yang sama. Ini akan melukai kesiapan dan membuat pemahaman kode semacam itu lebih menyakitkan (tapi ada hal yang lebih buruk yang dapat dilakukan seseorang untuk menghancurkan ketepatan kode).

Jika Anda menggunakan beberapa jenis aturan, Anda akan melihat sekilas misalnya:

CheckOut.getInstance () - ini adalah metode statis dari sebuah kelas yang disebut checkOut.calculate () - ini adalah metode objek yang disimpan dalam bidang variabel atau publik yang disebut _checkOut.calculate () - ini adalah metode objek yang disimpan dalam bidang pribadi yang disebut CHECKOUT - ini adalah bidang / variabel statis atau konstan akhir

tanpa memeriksa beberapa file lain atau bagian dari suatu file. Itu membuat membaca kode lebih cepat.

Saya melihat cukup banyak pengembang menggunakan aturan serupa - dalam bahasa yang sering saya gunakan: Java, PHP, Action Script, JavaScript, C ++.

Dalam kasus yang jarang terjadi, orang mungkin marah pada kasus yang tidak sensitif - misalnya ketika ingin menggunakan CheckOut untuk nama kelas dan checkOut untuk variabel dan tidak bisa karena saling bertabrakan. Tapi itu masalah seorang programmer yang digunakan untuk sensitivitas huruf dan menggunakannya dalam konvensi penamaannya. Seseorang dapat memiliki aturan dengan prefix standar atau postfix dalam bahasa yang tidak sensitif (saya tidak memprogram dalam VB tapi saya tahu bahwa banyak programmer VB memiliki konvensi penamaan seperti ini).

Dalam beberapa kata: Saya melihat sensitivitas huruf lebih baik (hanya untuk bahasa berorientasi objek) karena sebagian besar pengembang menggunakan bahasa case sensitif dan kebanyakan dari mereka menggunakan konvensi penamaan berdasarkan sensitivitas kasus sehingga mereka ingin lebih baik bahasa menjadi case sensitive sehingga mereka akan menjadi dapat tetap berpegang pada aturan mereka tanpa semacam modifikasi. Tapi itu argumen yang agak religius - bukan yang obyektif (tidak didasarkan pada kelemahan nyata atau sisi baik dari kepekaan kasus - karena saya tidak melihat ketika datang ke pengembang yang baik, ketika datang ke DeVeLoPeR bAd seseorang dapat menghasilkan kode mimpi buruk bahkan ketika ada sensitivitas kasus sehingga tidak ada perbedaan besar).

Bahasa pemrograman harus tidak peka huruf besar-kecil.

Alasan utama begitu banyak bahasa saat ini adalah case-sensitive hanyalah desain bahasa pemujaan: "C melakukannya seperti itu, dan C sangat populer, jadi itu pasti benar." Dan seperti dalam banyak hal lainnya, C salah membuktikan hal ini.

Ini sebenarnya adalah bagian dari filosofi mengemudi di belakang C dan UNIX: Jika Anda memiliki pilihan antara solusi buruk yang mudah diterapkan dan solusi bagus yang lebih sulit diterapkan, pilih solusi buruk dan dorong beban untuk mengatasi kekacauan Anda. pengguna. Ini mungkin terdengar seperti snark, tetapi itu benar-benar benar. Ini dikenal sebagai "prinsip buruk adalah lebih baik," dan itu secara langsung bertanggung jawab atas kerusakan bernilai miliaran dolar selama beberapa dekade terakhir karena C dan C ++ membuatnya terlalu mudah untuk menulis perangkat lunak yang glitchy dan tidak aman.

Membuat kasus bahasa tidak peka jelas lebih mudah; Anda tidak perlu tabel lexer, parser, dan simbol harus melakukan pekerjaan ekstra untuk memastikan semuanya cocok dengan case case peka. Tapi itu juga ide yang buruk, karena dua alasan:

• Pertama, terutama jika Anda sedang membangun bahasa scripting, salah ketik sederhana di mana Anda memanggil sesuatu "myObject" di satu tempat dan "MyObject" di tempat lain, di mana Anda jelas merujuk ke objek yang sama tetapi hanya sedikit tidak konsisten dengan huruf besar , tidak berubah menjadi kesalahan runtime. (Ini terkenal sebagai titik rasa sakit utama dalam bahasa scripting yang melakukan kesalahan ini, seperti Python.)
• Kedua, tidak memiliki sensitivitas case berarti sensitivitas case tidak dapat disalahgunakan untuk memiliki kata yang sama merujuk pada dua hal yang berbeda dalam cakupan yang sama hanya dengan mengubah kapitalisasi. Jika Anda pernah harus bekerja dengan kode Windows di lingkungan C, dan mengalami deklarasi jelek HWND hwnd;, Anda akan tahu persis apa yang saya bicarakan. Orang-orang yang menulis seperti itu harus dikeluarkan dan ditembak, dan membuat kasus bahasa tidak peka mencegah penyalahgunaan sensitivitas huruf masuk ke kode Anda.

Jadi, lakukan upaya ekstra untuk memperbaikinya. Kode yang dihasilkan akan lebih bersih, lebih mudah dibaca, lebih sedikit buggy, dan membuat pengguna Anda lebih produktif, dan bukankah itu tujuan akhir dari setiap bahasa pemrograman?

Saya tidak percaya bahwa seseorang berkata "sensitivitas huruf memudahkan membaca kode".

Pasti tidak! Saya telah melihat dari balik seorang rekan kerja pada variabel yang disebut Perusahaan dan perusahaan (Perusahaan variabel publik, perusahaan variabel pribadi yang cocok) dan pilihan font dan warnanya membuat sangat sulit untuk membedakan antara keduanya - bahkan ketika berdekatan satu sama lain.

Pernyataan yang benar harus "case campuran membuat membaca kode lebih mudah". Itu adalah kebenaran yang jauh lebih jelas - misalnya variabel yang disebut CompanyName dan CompanyAddress daripada nama perusahaan. Tapi tidak ada bahasa yang saya tahu membuat Anda hanya menggunakan nama variabel huruf kecil.

Konvensi paling gila yang saya tahu adalah "publik huruf besar, pribadi huruf kecil". Itu hanya meminta masalah!

Saya mengambil kesalahan adalah "lebih baik bahwa sesuatu gagal ribut dan sesegera mungkin daripada diam-diam gagal tetapi tampaknya berhasil". Dan tidak ada yang lebih cepat dari waktu kompilasi.

Jika Anda keliru menggunakan variabel huruf kecil ketika Anda bermaksud menggunakan huruf besar, itu akan sering dikompilasi jika Anda mereferensikannya dalam kelas yang sama . Dengan demikian, Anda dapat terlihat berhasil dalam kompilasi dan waktu menjalankan tetapi secara halus melakukan hal yang salah, dan mungkin tidak mendeteksinya untuk waktu yang lama. Ketika Anda mendeteksi bahwa ada sesuatu yang salah

Jauh lebih baik menggunakan konvensi di mana variabel pribadi memiliki akhiran - misalnya variabel publik Perusahaan, variabel pribadi CompanyP. Tidak ada yang akan secara tidak sengaja mencampuradukkan keduanya, dan mereka muncul bersama dalam intellisense.

Ini kontras dengan keberatan yang orang harus notasi Hungaria, di mana variabel pribadi yang diawali pPerusahaan tidak akan muncul di tempat yang baik di intellisesne.

Konvensi ini memiliki semua kelebihan dari konvensi huruf besar / kecil dan tidak ada kekurangannya.

Fakta bahwa orang merasa perlu untuk menarik kepekaan kasus untuk membedakan antara variabel menunjukkan baik kurangnya imajinasi dan kurangnya akal sehat, menurut pendapat saya. Atau, sayangnya, domba manusia suka kebiasaan mengikuti kebaktian karena "begitulah selalu dilakukan"

Buat hal-hal yang Anda kerjakan dengan jelas dan jelas berbeda satu sama lain, bahkan jika itu terkait !!

Anda tidak boleh membuat huruf besar-kecil tanpa alasan yang kuat untuk melakukannya. Misalnya, berurusan dengan perbandingan kasus dengan Unicode bisa menjadi menyebalkan. Sensitivitas kasus (atau ketiadaan) bahasa yang lebih tua tidak penting, karena kebutuhan mereka sangat berbeda.

Programmer di era ini mengharapkan sensitivitas kasus.

Sensitivitas huruf membuat kode lebih mudah dibaca dan pemrograman lebih mudah.

• Orang-orang menemukan penggunaan case campuran yang tepat lebih mudah dibaca .

• Itu memungkinkan / mendorong CamelCase sedemikian rupa sehingga kata yang sama dengan case berbeda dapat merujuk pada hal-hal terkait: Car car; Dengan demikian variabel bernama cardibuat jenis Car.

• ALL_CAPS_WITH_UNDERSCORES menunjukkan konstanta dengan konvensi dalam banyak bahasa

• all_lower_with_underscores dapat digunakan untuk variabel anggota atau sesuatu yang lain.

• Semua alat pemrograman modern (kontrol sumber, editor, diff, grep, dll) dirancang untuk sensitivitas case. Anda akan selamanya mengalami masalah dengan alat yang oleh programmer diterima begitu saja jika Anda membuat bahasa yang tidak sensitif.

• Jika bahasa akan ditafsirkan, mungkin ada penalti kinerja untuk parsing kode tidak sensitif.

• Bagaimana dengan karakter non-Inggris? Apakah Anda memutuskan sekarang untuk tidak pernah mendukung Koptik, Cina, dan Hindi? Saya sangat menyarankan Anda menjadikan bahasa Anda sebagai standar segalanya untuk UTF-8 dan yang mendukung beberapa bahasa yang memiliki karakter tanpa huruf besar atau kecil. Anda tidak akan menggunakan karakter ini dalam kata kunci Anda, tetapi ketika Anda mulai mematikan sensitivitas huruf pada berbagai alat (untuk menemukan hal-hal dalam file misalnya), Anda akan mengalami beberapa pengalaman nyata dan mungkin tidak menyenangkan.

Apa manfaatnya? 3 bahasa yang Anda sebutkan berasal dari tahun 1970-an atau sebelumnya. Tidak ada bahasa modern yang melakukan ini.

Di sisi lain, apa pun yang benar-benar membuat pengguna akhir senang membawa sedikit cahaya ke dunia. Jika itu benar-benar akan memengaruhi kebahagiaan pengguna, maka Anda harus melakukannya.

Jika Anda ingin membuatnya sangat sederhana untuk pengguna akhir, Anda dapat melakukan lebih baik daripada sensitivitas huruf / ketidakpekaan - lihat di Scratch ! Beberapa kucing kartun yang lebih sedikit dan lebih banyak warna yang ramah bisnis dan Anda memiliki tentang bahasa ramah yang pernah saya lihat - dan Anda tidak perlu menulis apa pun! Hanya pemikiran saja.