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


31

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?


4
Ya, Visual Basic umumnya tidak peka huruf besar kecil, apakah itu menjawab pertanyaan Anda? ; P
yannis


3
Perhatikan bahwa sangat sulit untuk membuat case case tidak peka, kecuali jika Anda membatasi pengguna untuk rangkaian karakter ASCII.
Simon Richter

2
@ MainMa: C ++ atleast tidak secara langsung. Ini memungkinkan karakter yang ditentukan implementasi dalam pengidentifikasi, tetapi yang dijamin hanya a-zA-Z, 0-9(kecuali di awal) dan _.
Xeo

2
VB6 sebenarnya menggunakan semacam pendekatan hybrid: Anda dapat menulis kata kunci dan pengidentifikasi dengan cara apa pun yang Anda inginkan dan IDE segera mengubahnya menjadi cara tersimpan. (Anda bahkan dapat menulis "endif" dan itu akan dikonversi menjadi "End If".)
Felix Dombek

Jawaban:


42

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.


Pikirkan sistem file mana yang peka huruf besar-kecil sebelum melihat bahasa pemrograman. FAT / NTFS untuk Windows dan HFS + untuk MacOS X keduanya case-sensitive, sedangkan UFS / NFS untuk Unix peka terhadap huruf besar-kecil. Pengguna yang kuat menyukai kemampuan untuk membedakan file / variabel dengan perbedaan kecil sementara sebagian besar pengguna lebih suka menjaga hal-hal lebih intuitif. Seperti yang dikatakan Avner, perbedaannya adalah pilihan manajemen produk.
Michael Shopsin

4
Karena ini adalah bahasa scripting, itu adalah no-brainer - kasus sensitif adalah cara untuk pergi. Mengapa peka terhadap huruf besar-kecil? Jika jawabannya "menjadi seperti C dan Java", apakah itu benar-benar alasan yang bagus?
Ben

15
@Ben Python, Ruby, bash, Lua dan Perl adalah contoh bahasa scripting yang sangat populer yang peka terhadap huruf besar-kecil. Bahasa yang tidak peka huruf besar kecil mencakup bahasa perusahaan seperti Delphi dan SQL (dan COBOL IIRC, jika Anda hitung itu). Mengapa ia tidak punya otak untuk bahasa scripting, dan mengapa para perancang bahasa scripting terbesar di dunia tidak setuju?

2
Itu tidak bisa menjadi no-brainer karena menjadi bahasa scripting - pertanyaan yang relevan adalah: siapa yang melakukan scripting, dan apa pilihan terbaik bagi mereka? (Saya juga akan mengatakan bahwa Anda mungkin harus konsisten: jika kata kunci Anda adalah case-sensitive, silakan tidak membuat pengidentifikasi case-sensitive ...)
comingstorm

@delnan Saya pikir itu adalah pilihan logis bahwa bahasa scripting menargetkan OS di mana case-sensitive juga harus case-sensitive.
Artemix

16

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".


3
+1 untuk "apakah perbedaan ini akan berarti bagi pengguna". Yang paling penting pengguna.
Ben

Mengapa SQL lebih mudah digunakan dalam pengaturan interaktif karena case-insensitivity? Apakah karena Anda secara tidak sengaja dapat mengaktifkan Caps Lock dan tidak memperhatikan?
Kaz

@ Ka - Cukup banyak.
ChrisF

11

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.


1
"Bagaimana dengan bahasa Prancis: apakah kamu menganggap È dan è sama? Atau bahasa Jepang? Apakah kamu menganggap hiragana dan katakana hanya sebagai kasus, sehingga フ ァ イ ル dan ふ ぁ い る adalah pengidentifikasi yang sama?" Jawabannya adalah "ya", dan itu hanya kebodohan jika Anda berpikir budaya orang lain itu bodoh.
Ben

Nah, bersiaplah untuk kepala kecil Anda meledak, karena saya tidak berpikir budaya orang lain bodoh (dengan pengecualian tertentu, sehubungan dengan peristiwa terkini di dunia), namun pada saat yang sama saya pikir itu benar-benar bodoh untuk memperlakukan フ ァ イ ル danふ ぁ い る sebagai pengidentifikasi yang sama dalam bahasa pemrograman.
Kaz

@ Apakah Anda tahu budaya yang disebutkan? Jika Anda tahu apa yang dibicarakan Kaz, Anda tidak akan menyebutnya bodoh.
David Cowden

1
@ Davidvidow, aku tidak pernah menyebut Kaz bodoh. Saya setuju seseorang harus selalu menggunakan kasus yang sama di mana pun seseorang menggunakan pengenal. Perbedaan Kana lebih signifikan daripada perbedaan huruf besar, sama seperti perbedaan aksen lebih penting daripada perbedaan huruf besar kecil. Namun sama konyolnya untuk memiliki dua pengidentifikasi yang hanya berbeda berdasarkan kasus, juga konyol untuk memiliki dua pengidentifikasi yang hanya berbeda oleh kana atau dengan aksen. Lebih masuk akal untuk melarang pengidentifikasi yang berbeda hanya dengan kana atau aksen daripada memperlakukannya sama, tetapi sangat tidak masuk akal untuk memperlakukan mereka sebagai berbeda.
Ben

Jika Anda melarang pengidentifikasi yang hanya berbeda dalam hal, aksen, atau kana atau apa pun, maka Anda secara diam-diam mengakui bahwa mereka sama (tetapi hanya bersikeras pada konsistensi). Lebih baik untuk tidak membuang hal-hal seperti itu, dan menyerahkannya kepada pengguna untuk masalah konvensi pengkodean. Gagasan yang lebih baik adalah memiliki sistem deklaratif di mana program dapat menyatakan bahwa foodan Foodiperlakukan sebagai sinonim atau berbeda. Tanpa pernyataan seperti itu, itu adalah kesalahan bagi keduanya terjadi. Dan karena deklarasi tidak diperpanjang FOO, maka FOOmasih dilarang; itu harus ditambahkan.
Kaz

6

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.


Saya tidak berpikir ingin menggunakan kembali kata kunci untuk nama adalah masalahnya. SQL, Visual Basic, dan C # (dua case-sensitive dan case-sensitive) keduanya menyelesaikan ini dengan memungkinkan cara untuk mengutip pengidentifikasi: "double quotes"(atau [brackets]dalam MS SQL) dalam SQL, [brackets]di VB.net, dan @atsigndi C #.
Random832

"seberapa sering kamu ingin memiliki banyak hal dengan nama yang sama." Ketidaksensitifan huruf berarti Anda harus menambahkan beberapa biaya tambahan untuk mendamaikan nama yang jika tidak akan ditangani dengan huruf besar-kecil (mis. M sebagai awalan untuk 'anggota' untuk membedakan dari nama properti yang tidak diperbaiki, katakanlah).
nwahmaet

Mengapa Anda memberi nama objek objek? Itu hanya meminta masalah.
Ben

@ Ben, misalkan Anda menerapkan objek kontainer, apa lagi yang akan Anda panggil parameter ke metode add Anda?
Winston Ewert

@ WinstonEwert, saya akan menyebutnya o. Tidak masalah apa yang Anda panggil karena itu hanya nama parameter. Selama itu tidak menyinggung atau ilegal, atau dapat menyebabkan kebingungan .
Ben

5

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.


Poin bagus, tapi bukan jawaban.

@delnan: mungkin bukan jawaban sebagus yang dari Avner Shahar-Kashtan (kepada siapa saya memberi +1), tetapi mungkin membantu untuk OP.
Doc Brown

3
Ya, membantu sebagai komentar;)

Jadi jika ini ditulis ulang untuk mengatakan itu hanya ide yang baik jika Anda memperingatkan pengguna tentang sensitivitas huruf besar maka itu akan menjadi jawaban? Bagi saya, itu dianggap.
JeffO

Tidak, maka itu akan menjadi poin kecil yang hampir tidak menjawab pertanyaan yang diutarakan sebagai jawaban. MENURUT OPINI SAYA.

4

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.


2
IMHO itu membuat membaca lebih mudah juga. Lagi pula ketika Anda memulai kalimat, Anda menggunakan huruf besar kata pertama, Tapi Anda tidak mengubah artinya. Seharusnya sama untuk kode!
NWS

2
@delnan - Anda ingin keterbacaan, ia menggunakan alfabet yang sama, Mengapa mengubah artinya ketika Anda mengubah huruf besar-kecil?
NWS

1
@delnan, menurut Mahkamah Agung Amerika Serikat, bahasa komputer adalah bahasa ekspresif yang dirancang untuk dipahami oleh komputer dan manusia (ketika memutuskan bahwa kode komputer dilindungi oleh amandemen pertama). Mereka bukan bahasa Inggris, tetapi mereka adalah bahasa, dan mengatakan "BOB" berbeda dari "bob" berbeda dari "Bob" bodoh dalam bahasa apa pun yang dimaksudkan untuk digunakan oleh manusia. Ya, kita bisa belajar mengatasinya, tetapi itu bukan alasan apa pun.
Ben

2
@ Ben Biarkan saya membuat analogi. Notasi matematika, tidak seperti bahasa pemrograman, khusus untuk manusia. Argumen biasa tentang ketidakpekaan kasus sebagai artefak historis komputer kuno tidak berlaku di sini. Namun saya ragu seorang ahli matematika akan berpendapat bahwa adan Aharus dipertukarkan. Mereka menangani secara konsisten, tanpa pengecualian. Misalnya, dalam beberapa konteks huruf besar digunakan untuk set sedangkan huruf kecil ditetapkan sebagai anggota. Contoh lain terjadi dalam teknik elektro, huruf kecil tergantung pada waktu dan huruf besar bergantung pada waktu ...

2
@ Ben ... dalam konteks ini dan lainnya, saya tidak melihat sensitivitas huruf sebagai batasan. Saya melihatnya sebagai membebaskan simbol yang berlebihan untuk digunakan dengan cara yang lebih produktif, melalui konvensi yang mengkomunikasikan makna, antara lain, dengan huruf besar. Seperti halnya notasi khusus domain singkat, ini mungkin terasa asing bagi orang awam tetapi memungkinkan para ahli untuk berkomunikasi lebih baik dan lebih cepat.

2

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.


4
Saya muak dengan argumen "X itu baik, Y memberlakukan hal yang terkait Z, oleh karena itu Y melakukan yang baik dengan menegakkan X" (mis. Gaya pengkodean yang waras / Python / aturan offside). Tidak ada pemrogram yang baik yang memanfaatkan dengan cara yang berdampak serius terhadap keterbacaan, bahkan ketika diizinkan. Mereka yang melakukan penyalahgunaan ketidaksensitifan kasus juga menggunakan huruf besar secara tidak konsisten dalam lingkungan yang peka terhadap kasus (dan melakukan seratus kekejaman lainnya), mereka hanya dipaksa menggunakan kapitalisasi buruk yang sama untuk setiap penggunaan nama individu. Pemrogram yang buruk dapat menulis Fortran dalam bahasa apa pun. (Penafian: Saya penggemar berat sensitivitas kasus!)

Tebak apa. Saya muak harus membaca kode yang ditulis oleh programmer buruk yang berpikir mereka adalah programmer yang baik sehingga mereka dapat mengembangkan aturan gaya unik mereka sendiri. (Penafian: Saya belajar memprogram pada zaman FORTRAN dan COBOL, dan saya membenci ketidakpekaan terhadap kasus dan kekejaman linguistik lainnya dari zaman itu.)
Stephen C

Setiap penggunaan huruf besar apa pun dalam bahasa tidak sensitif kasus merupakan penyalahgunaan ketidakpekaan.
Kaz

@ Kaz - erm ... coba katakan itu kepada sejuta programmer SQL.
Stephen C

1

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).


Sensitivitas casing tidak mengutamakan kenyamanan komputer lebih dulu daripada pengguna. Saya telah menerapkan huruf besar-kecil dan tidak peka huruf besar-kecil, dan satu-satunya perbedaan adalah pemanggilan fungsi tambahan di beberapa tempat. Juga, jawaban lain mengatakan bahwa kasus di -sensitivity adalah artefak sejarah karena set karakter terbatas - bertentangan teori Anda, bukan?

Unicode menempatkan ini di ranah lain sepenuhnya.
DeadMG

3
Blog itu tidak memberikan alasan mengapa C buruk, hanya dalam Python atau PHP- dan OP tidak berbicara tentang pengenal huruf besar-kecil, hanya kata kunci . Tautan itu sama sekali tidak ada hubungannya dengan subjek itu.
DeadMG

1
@Ben Editor dapat (dan melakukan) memperbaiki casing saat Anda mengetik terlepas dari aturan bahasa. Membiarkan kesalahan yang lolos (mis. Karena Anda tidak memiliki editor yang bagus) tidak membantu. Itu berarti meninggalkan masalah, bukannya mengeluh tentang hal itu untuk memperbaikinya. Terlebih lagi, begitu saya menggunakan huruf besar yang konsisten, saya dapat memiliki banyak pengidentifikasi yang berbeda dalam hal ini, tetapi menunjukkan hal-hal yang sangat berbeda dan menjadi mudah diurai untuk manusia berkat konteks dan huruf besar, tanpa ambiguitas.

2
@ Ben: Dalam beberapa bahasa, ada kebiasaan leksografis yang sangat ketat, atau bahkan aturan. Dalam C dan C ++, all-caps adalah makro, dan makro harus tetap all-caps untuk mencegah kebingungan. Beberapa bahasa memiliki arti berbeda untuk simbol dengan atau tanpa batas awal (dan saya tidak tahu seberapa baik mereka melakukannya dalam berbagai bahasa yang tidak memiliki huruf besar dan kecil yang sesuai). Jika Anda memiliki aturan atau konvensi seperti itu, Anda mendapatkan efek dari ruang nama yang berbeda, dan duplikat nama pengenal di ruang nama yang berbeda sering berhasil.
David Thornley

1

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).


1

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?


Bahasa pemrograman harus memiliki ruang lingkup leksikal untuk menangkap jenis kesalahan ini sebelum waktu berjalan (bahkan jika mereka sangat dinamis). Lisp umum adalah bahasa yang sangat dinamis, namun kompiler memberi tahu kami ketika kami telah menggunakan variabel yang tidak memiliki pengikatan leksikal dan tidak secara global didefinisikan sebagai variabel dinamis. Anda tidak dapat bergantung pada ketidakpekaan huruf besar-kecil untuk ini karena Anda ingin menangkap semua kesalahan ketik, tidak hanya yang melibatkan huruf besar-kecil.
Kaz

Saya tidak keberatan HWND hwnd;. Ini adalah contoh di mana sensitivitas case bekerja dengan baik. Konvensi "Indian Hill" semua topi semuanya konyol. hwnd_t hwndjauh lebih baik. Saya curiga itu semua karena FILE. Sekali waktu Version 6 Unix telah di / file I nya O sundulan perpustakaan ini: #define FILE struct _iobuf. Itu semua dalam topi karena itu makro. Ketika menjadi typedef di ANSI C, ejaan semua huruf dipertahankan. Dan saya pikir dengan meniru inilah konvensi ALL_CAPS_TYPE ditemukan, dan dikodifikasikan dalam Bell Lab "Panduan Gaya Indian Hill. (Yang asli!)
Kaz

Jika sekarang Anda mencari "Panduan Gaya Bukit Indian" di India, Anda akan menemukan sebagian besar referensi ke dokumen tahun 1990 dari Bell Labs yang sepenuhnya bertobat dari nama semua huruf typedef: tidak ada jejak rekomendasi tersebut. Tetapi versi aslinya merekomendasikan hal-hal seperti typedef struct node *NODE. Saya yakin di situlah Microsoft harus mengambil ini. Jadi, salahkan Bell Labs HWND.
Kaz

1

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 !!


1
Oke, jadi companyName == companyname. Tampaknya masuk akal, tetapi bagaimana Anda menangani lokal? Apakah mengkompilasi program Anda di berbagai belahan dunia akan menyebabkan semantik yang berbeda, seperti halnya dalam PHP? Apakah Anda akan sepenuhnya Anglo-sentris dan hanya mendukung set pengidentifikasi ASCII yang dapat dicetak? Ketidakpekaan case banyak kompleksitas tambahan untuk keuntungan ekstra sangat sedikit.
Phoshi

0

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.


1
Perbandingan kasus tidak terlalu sulit. Cukup terurai pengidentifikasi Anda. É = E '= e' = é. Ingat, Anda masih dapat memilih aturan kasus mana yang harus diikuti, dan bahasa Inggris adalah pilihan yang masuk akal. (tentu saja jika kata kunci Anda adalah bahasa Inggris juga)
MSalters

2
Ya mereka "sangat sulit", melintasi seluruh ruang Unicode.
Kaz

1
"Pemrogram di era ini mengharapkan sensitivitas huruf"? Hanya jika mereka memiliki Sindrom Stockholm karena terlalu lama bekerja dengan keluarga C.
Mason Wheeler

Nah, keluarga C hanya menyumbang, seperti, proporsi bahasa dan kode yang sangat besar. Selain itu, saya pikir itu hal yang baik dan komentar Anda tidak mengajukan alasan mengapa tidak.
DeadMG

0

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.


1
Saya pikir Anda ingin mengatakan "case-insensitivity is a nightmare". Jepang memang punya kasus: hiragana dan katakana adalah, jenis, kasus yang berbeda. Sama seperti A dan a "sama" dengan cara tertentu, begitu juga あ dan ア. Katakana kadang-kadang digunakan untuk penekanan, sama halnya huruf besar dalam bahasa yang menggunakan alfabet roman. Tak perlu dikatakan, akan sangat konyol untuk memperlakukan hiragana dan katakana sebagai sama dalam pengidentifikasi bahasa pemrograman.
Kaz

Terima kasih - itu memperkaya! Saya membersihkan posting saya hanya sedikit.
GlenPeterson

1
Car car;adalah salah satu argumen terbaik terhadap sensitivitas kasus: jelek, dan jika bahasa Anda tidak peka terhadap huruf besar-kecil, Anda tidak dapat menyalahgunakan sensitivitas huruf besar-kecil dengan cara itu.
Mason Wheeler

1
Apakah Car myCar;jauh lebih baik?
GlenPeterson

@Mason Wheeler: Jika kita membatasi konstruksi bahasa kita pada hal-hal yang tidak dapat kita penyalahgunaan, kita tidak akan bisa berbuat banyak, bukan? Saran saya kepada siapa pun yang menyalahgunakan sensitivitas kasus adalah "Jangan".
David Thornley
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.