Mengapa masih ada sensitivitas case dalam beberapa bahasa pemrograman?


44

Saya tidak melihat ada gunanya sensitivitas case dalam bahasa pemrograman, selain dari kode yang membingungkan.

Mengapa menerapkan ini dalam bahasa pemrograman?

Memperbarui:

Sepertinya seseorang yang Anda kenal membuat pernyataan tentang ini .


28
Mengapa masih ada beberapa kasus dalam beberapa bahasa pemrograman?
Thomas Eding

1
Bahkan bahasa Inggris pada umumnya peka terhadap huruf besar-kecil. Contoh umum yang dikutip adalah Polandia dan Polandia yang merupakan dua istilah berbeda yang bentuk tulisannya hanya berbeda dalam hal dan yang memiliki pengucapan dan makna yang berbeda. IMO lebih baik untuk pemrograman tidak terlalu pintar dalam hal ini dan biarkan programmer sendiri membuat konvensi tertulis yang sesuai. Misalnya cukup umum untuk menulis sesuatu seperti Person person = new Person()dalam bahasa OO di mana simbol 'orang' adalah objek sementara dan 'Orang' adalah tipe kelas.
Brandin

Jawaban:


113

Sementara lipat case cukup sepele dalam bahasa Inggris, itu jauh lebih sedikit dalam beberapa bahasa lain. Jika seorang programmer Jerman menggunakan ßnama variabel, apa yang akan Anda pertimbangkan setara huruf besar? Hanya FYI, "ß" hanya digunakan dalam huruf kecil. OTOH, "ss" adalah setara - apakah Anda menganggap kompiler wajib mencocokkannya? Saat Anda masuk ke Unicode, Anda akan mendapatkan masalah yang lebih menarik, seperti karakter dengan tanda diakritik yang sudah dikomposisikan sebelum digabungkan dengan menggabungkan diakritik. Kemudian Anda sampai pada beberapa naskah Arab, dengan tiga bentuk terpisah dari banyak surat, bukan hanya dua.

Pada zaman kegelapan, sebagian besar bahasa pemrograman tidak peka terhadap huruf besar-kecil karena kebutuhan. Sebagai contoh, Pascal dimulai pada mainframe Data Kontrol, yang hanya menggunakan enam bit per karakter (64 kode, total). Sebagian besar mesin seperti itu menggunakan set karakter "CDC Scientific", yang hanya berisi karakter huruf besar. Anda dapat beralih ke rangkaian karakter lain, tetapi sebagian besar memiliki huruf besar atau huruf kecil, tetapi tidak keduanya - tetapi menggunakan kode yang sama untuk keduanya. Hal yang sama berlaku untuk kode Baudot kuno dan standar yang dianggap seperti itu pada hari-hari awal COBOL, FORTRAN, BASIC, dll. Pada saat lebih banyak perangkat keras yang mampu tersedia secara luas, kepekaan case-nya sudah tertanam dengan sangat teliti sehingga mengubah itu tidak mungkin .

Seiring waktu, kesulitan nyata dari ketidakpekaan kasus menjadi lebih jelas, dan perancang bahasa sebagian besar telah memutuskan ("menyadari" mungkin akan menjadi istilah yang lebih akurat) bahwa ketika / jika orang benar-benar menginginkan ketidakpekaan kasus, bahwa itu lebih baik ditangani oleh alat bantu tambahan dari pada bahasa itu sendiri.

Setidaknya IMO, kompiler harus mengambil input persis seperti yang disajikan, bukan memutuskan bahwa "Anda menulis ini, tapi saya akan menganggap Anda benar-benar berarti sesuatu yang lain." Jika Anda ingin terjemahan terjadi, Anda lebih baik melakukannya secara terpisah, dengan alat yang dibangun untuk mengatasinya dengan baik.


26
+1, akan mengatakan sesuatu yang serupa, dalam pengalaman saya kebanyakan orang yang mengeluh tentang ini adalah orang yang sama yang tidak mempertimbangkan bahasa / perangkat char lainnya.
Jeremiah Nunn

5
Pertanyaan besar saya juga, jika kompiler akan mulai memperhatikan ejaan yang berbeda, haruskah itu memungkinkan Anda untuk secara sewenang-wenang menempatkan garis bawah di dalam atau "pemisah kata" lainnya? Apakah mungkin mencoba "melakukan apa yang Anda harapkan" ketika Anda salah mengeja pengenal? Seberapa jauh jaraknya? (BTW, Ada memungkinkan menggarisbawahi secara sewenang-wenang di dalam angka untuk alasan kejelasan.)
dash-tom-bang

3
@ Larry: Keduanya hampir sama - hampir setiap bahasa lain di dunia membutuhkan karakter yang tidak tersedia di ASCII. Dalam hal ini, meskipun kami semacam bertahan, itu agak terbatas bahkan untuk bahasa Inggris - misalnya, memaksa Anda untuk menulis "kerjasama" sebagai "kerja sama". Untungnya, mesin tik membuat orang terbiasa dengan pembatasan seperti itu jauh sebelum komputer muncul, sampai-sampai beberapa orang bahkan mempertimbangkan kemungkinan menggunakan semua karakter yang sebelumnya dianggap perlu.
Jerry Coffin

2
@ dash-tom-bang: kompiler telah ditulis yang mencoba melakukan hal-hal seperti itu (memperbaiki ejaan dan apa-tidak). Pengalaman menunjukkan bahwa biasanya lebih baik membuat kompiler berjalan lebih cepat dan menghasilkan pesan kesalahan yang lebih baik.
Jerry Coffin

2
@ saluran Atau "SZ". Argumen yang baik dapat dibuat untuk keduanya.
Vatine

114

Mengapa ada yang INGIN peka terhadap kasus? Dalam skenario apa berguna untuk dapat merujuk ke variabel tunggal seperti VARIABLEdi satu tempat, Variabledi tempat lain, dan variabledi tempat ketiga? Ketidakpekaan case menjengkelkan. Saya lebih suka mendapatkan kesalahan kompiler ketika saya tidak sengaja mengetik VAriablealih- Variablealih membiarkan case-typos seperti itu masuk ke dalam kode saya.

Kesimpulannya, banyak bahasa pemrograman memiliki sensitivitas huruf besar bukan hanya karena alasan historis / inersia tetapi karena ketidakpekaan huruf adalah ide yang buruk.


12
Anda melihatnya dari dalam ke luar. Ya, merujuk ke variabel yang sama dengan beberapa ejaan bisa menjengkelkan, tapi sama sekali tidak seburuk memiliki dua pengidentifikasi berbeda yang merujuk pada dua hal yang berbeda, dalam cakupan yang sama, yang hanya berbeda dalam kasus. Ketidakpekaan case adalah hal yang baik karena mencegah hal itu. (Plus, itu membuat kesalahan ketik sederhana dari menjadi kesalahan sintaksis; lihat tautan dalam pertanyaan ke posting Jeff pada subjek.)
Mason Wheeler

88
Tapi saya ingin kesalahan ketik yang sederhana menjadi kesalahan sintaks! Saya tidak ingin kesalahan ketik sederhana dalam kode saya dan saya ingin kompiler saya membantu saya menemukannya. Ketidakpekaan case membuatnya lebih sulit untuk menemukan mereka. Ketidaksensitifan kasus sepertinya merupakan alasan untuk pengkodean yang ceroboh.
nohat

4
@nohat: Saya setuju, ketika Anda mengetik apa pun selain apa yang Anda maksudkan, kesalahan sintaks adalah hal yang baik .
Tim Goodman

13
@Mason Wheeler, saya telah membaca artikel itu dan saya tidak bisa tidak setuju lagi. Saya telah menggunakan banyak bahasa yang tidak peka terhadap huruf besar-kecil dan saya terus-menerus kesal dengan kesalahan ketik.
nohat

11
Sepenuhnya setuju dengan ketidakpekaan case nohat adalah ide yang konyol - dan biasanya para pendukung datang dari orang-orang yang masih merindukan VB / Basic hari tua yang baik.
Tim

27

Dalam Java case sensitivitas TIDAK digunakan untuk memberikan lebih banyak opsi dalam kode, tetapi lebih untuk makna semantik yang sangat jelas dan konsisten. Kelas Lihat Seperti Ini. benda LihatLikeThis. methodsLookLikeThis (). STATIC_VARIABLES_LOOK_LIKE_THIS. Kelas. Dengan kacamata dalam, lihat seperti ini. Ini TIDAK memberikan kebebasan yang lebih besar: itu memungkinkan Anda untuk mengemas beberapa informasi secara ringkas ke dalam apa yang merupakan bahasa yang terlalu bertele-tele.

Saya pikir dalam bahasa yang diketik secara statis secara statis dengan banyak kompiler dan dukungan IDE, sensitivitas huruf adalah cara yang bagus untuk mengkomunikasikan informasi (misalnya, Java). Dengan bahasa seperti Ruby, ketidakpekaan huruf besar kemungkinan akan menyebabkan hasil LEBIH BANYAK yang tak terduga, meskipun saya akan terbuka untuk mencoba Ruby yang tidak peka terhadap huruf besar-kecil.

Saya pikir sensitivitas case dengan sistem yang ketat tidak mengaburkan kode tetapi sebenarnya membuatnya lebih jelas. Pertimbangkan kemungkinan kode Java:

      joe blah = new hUf();

itu cukup jelas, tetapi bagaimana dengan:

      hUf.WTF();

Di Java apa adanya, Anda akan secara otomatis tahu apa ini. Dalam Java case-insensitive, ini ambigu, jadi Anda harus menggunakan beberapa mekanisme lain untuk membedakan kelas dari instance dari paket dari metode. Dan mekanisme itu mungkin akan membuat Anda muntah dengan betapa buruknya itu :)


2
Tidaaaak! BUKAN LEBIH BANYAK BAWAH !! int package_class_method_var_name? !!
Michael K

2
@Michael, aneh bagaimana tampaknya tidak ada yang menyadari bahwa garis bawah adalah kerumitan untuk mengetik.
Dan Rosenstark

2
itu tergantung pada keyboard Anda. Bagi saya (menggunakan keyboard Prancis), _ mudah diketik, {} jauh lebih sulit (menggunakan AltGr untuk menjangkau mereka).
PhiLho

6
Ah, jadi sensitivitas huruf adalah notasi Hongaria yang baru.
David Thornley

1
Ini hanya " makna semantik yang sangat jelas dan konsisten " jika kompiler memaksakannya. Sekarang, kompiler yang membutuhkan nama kelas untuk memulai dengan karakter huruf besar dan nama metode dengan huruf kecil sebenarnya bisa menjadi alasan yang menarik untuk memiliki sensitivitas huruf.
Ross Patterson

24

Saya tidak berpikir itu "diimplementasikan" sebanyak "diizinkan." Sensitivitas huruf adalah keadaan standar perbandingan string; dibutuhkan kerja ekstra untuk insinyur kompiler untuk membuat bahasa tidak sensitif, karena Anda perlu menambahkan kode tambahan untuk melakukan perbandingan tidak sensitif-huruf dan mempertahankan nama token asli untuk kesalahan dan pelaporan peringatan yang benar.

Itu hampir pasti mengapa berakhir di C; mereka ingin membuat bahasa sederhana yang mudah diimplementasikan untuk kompiler, dengan mengorbankan kegunaan. Adapun mengapa itu di bahasa modern? Karena itu dalam C, tentu saja, jadi itu harus menjadi cara yang tepat untuk melakukannya! </ Mode sarkasme>


3
Plus, saya pikir kembali di tahun 60an dan 70an ketika bahasa pemrograman sedang diciptakan, ruang dan kecepatan SANGAT penting. Kami tidak mampu membeli instruksi dan ruang ekstra untuk membandingkan case-insensitve. Ini lebih merupakan masalah "begitulah selalu terjadi" dalam bahasa modern. Tidak ada alasan untuk bahasa baru (seperti C #) untuk melakukan ini.
Jay

1
@ Jay: Namun, untuk alasan apa pun, Pascal, yang ada sebelum C dan memengaruhi desainnya, tidak peka huruf besar-kecil dan masih dapat dikompilasi lebih cepat. ;)
Mason Wheeler

@Mason: Saya tidak berpikir pascal memengaruhi C ... Saya harus mencarinya. Pada dasarnya, mereka semua berasal dari Algol / Fortran! people.mandriva.com/~prigaux/language-study/diagram.png
Jay

1
@ Matt: Umm ... dari mana Anda mendapatkan itu? Semua sumber daya yang saya lihat berasal dari Pascal hingga 1970 dan C hingga 1972.
Mason Wheeler

16
Anak-anak zaman sekarang. Kembali di hari saya, kami tidak memiliki huruf kecil, dan kami menyukainya. 6 bit sudah cukup. Tentu saja, sekarang kita semua tuli dari SHOUTING.
KeithB

23

Jika tidak ada yang lain, ini menyederhanakan penguraian dan memungkinkan Anda lebih banyak kombinasi untuk nama variabel / kelas.

Dengan penguraian case-insensitive, Anda akan diharuskan untuk menggunakan pengidentifikasi unik, karena 'myClass' dan 'MyClass' akan menjadi hal yang sama. Sebagai alternatif, Anda harus menambahkan lapisan kompleksitas ke parser Anda untuk memastikan Anda dapat menentukan pengidentifikasi yang digunakan berdasarkan konteks.

Pertimbangkan kasus seperti ini:

XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");

Misalkan kelas XmlWriter juga memiliki metode statis yang disebut "Tulis". Apakah Anda menyebutnya pada instance atau di kelas, jika tidak ada case-sensitivitas yang diterapkan di sini?


14
Tapi itu konvensi penamaan yang buruk. Saya akan mencekik seseorang jika writedan Writedua metode yang sama sekali berbeda.
TheLQ

5
Harus setuju dengan TheLQ yang satu ini. Ini membuat saya gila ketika saya sedang bekerja di beberapa perpustakaan C dan saya melihat deklarasi seperti "HWND hwnd;". Siapa pun yang menyalahgunakan sensitivitas kasus seperti ini harus dikeluarkan dan ditembak.
Mason Wheeler

4
@TheLQ metode memiliki kasus yang sama. Saya menggunakan kasus yang berbeda dalam nama kelas / variabel sebagai contoh saya.
Adam Lear

6
@ Anne Lear, saya pikir ini adalah contoh yang buruk. Dengan bahasa yang tidak sensitif huruf, Anda tidak perlu khawatir tentang metode apa yang harus dihubungi karena Anda sudah memiliki kesalahan sintaks ketika mencoba menggunakan nama kelas untuk nama variabel.
Matt Olenik

5
@ Mat Anda tidak boleh kode tanpa highlight sintaks. Saya bisa mengerti tanpa IDE, tetapi coding dalam editor tanpa menyoroti sintaks ... mengapa ada orang yang melakukan itu untuk diri mereka sendiri?
Davy8

13

Saya suka sensitivitas huruf jika tanpa alasan lain selain membuat kode lebih mendokumentasikan diri:

this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename

Saya biasanya memprogram dengan Python, tetapi kembali pada hari C # saya, saya merasa sangat nyaman untuk memberi nama instance kelas yang sama dengan kelas, tetapi huruf kecil (atau unta) (seperti yang orang lain katakan):

Thing thing = new Thing();

Menggunakan bahasa yang case-sensitive membutuhkan beberapa konvensi lain untuk ini, yaitu, semacam sigil seperti:

Thing oThing = new Thing()
Thing instanceOfThing = new Thing()

Yang merupakan "hal buruk".

Saya juga merasa nyaman untuk grep (case-sensitive) untuk menemukan referensi ke kelas vs penggunaan variabel. Dengan bahasa yang tidak peka huruf besar kecilnya, ini akan menjadi tidak mudah. Sama untuk pencarian & ganti.

Terakhir, sebagai seorang programmer, ketika saya melihat kata-kata dengan kasus yang berbeda, saya tahu bahwa itu adalah hal yang berbeda ... Saya jarang memiliki bug di mana kasus variabel salah, bahkan dalam bahasa skrip dinamis, di mana kompiler akan membantu.


10

Orang memperhatikan bentuk kata sebelum mereka benar-benar membacanya. Sensitivitas case menjaga bentuk simbol konsisten di seluruh kode. Saya juga setuju dengan yang di atas yang menyatakan bahwa konvensi yang berbeda menunjukkan jenis simbol yang berbeda. Sensitivitas dan sensitifitas kasus keduanya dapat disalahgunakan. Pemrogram yang buruk akan selalu menghasilkan kode yang buruk ... mereka akan menemukan jalan.

Ambil bahasa sebagai contoh. Mengapa kita memulai kalimat dan menamai benda dengan huruf kapital ... Apakah itu juga karena unix?


@JUST Komentar dimaksudkan untuk mencari klarifikasi, bukan untuk diskusi panjang. Jika Anda punya solusi, tinggalkan jawaban. Jika solusi Anda sudah diposting, harap perbarui. Jika Anda ingin mendiskusikan jawaban ini dengan orang lain, silakan gunakan obrolan . Lihat FAQ untuk informasi lebih lanjut.
Adam Lear

9

Saya pikir untuk lanaguage yang diketik secara statis seperti C # dan Java, itu tidak benar-benar menambah nilai. Karena dalam kebanyakan kasus, Anda memiliki IDE yang akan memperbaiki ketidaksesuaian case secara otomatis untuk Anda, jadi pada akhirnya, jika saya mengetik "VAriable" secara tidak sengaja, IDE saya akan memperbaiki secara otomatis untuk " Variabel "untuk saya. Tambahkan ke MyClass myClass;konvensi gaya dan Anda dapat melihat bahwa sensitivitas case tidak selalu merupakan hal yang buruk.

Untuk bahasa yang diketik secara dinamis, mungkin ada lebih banyak argumen, karena lebih sulit bagi IDE untuk menebak koreksi otomatis, tetapi dalam kasus bahasa yang diketik secara dinamis, Anda sudah punya banyak hal yang perlu dikhawatirkan (dalam hal kesalahan ketik) bahwa menggunakan konvensi casing yang konsisten tidak akan menambah beban yang jauh lebih banyak.

Jadi ya, sementara tidak ada alasan nyata bahasa tidak bisa tidak peka terhadap huruf besar-kecil, juga tidak ada alasan nyata mengapa mereka harus memilih keduanya.

Artikel dari Scott Hanselman tentang "SignOn" vs "Signon" adalah tentang perbandingan string, dan tidak ada hubungannya dengan bahasa pemrograman. Saya setuju bahwa string yang diketikkan oleh pengguna harus selalu dibandingkan dengan case-insensitive, tapi saya pikir itu adalah ballgame yang berbeda dengan pengidentifikasi dalam bahasa pemrograman.


1
+1 untuk menyebutkan "IDE yang akan memperbaiki ketidaksesuaian case secara otomatis"
DavRob60

3
IDE adalah untuk para pengecut. Saya memprogram dengan pensil dan kertas, dan kemudian memindai kodenya.
Dan Rosenstark

6

Ketika suatu bahasa peka terhadap huruf besar-kecil, saya memanfaatkannya untuk mereproduksi penggunaan kasus konvensional dalam matematika dan sains. Berikut adalah daftar (tidak berarti lengkap) dari beberapa konvensi kasus:

  • Dalam teori probabilitas, huruf kecil fbiasanya mewakili fungsi kerapatan probabilitas (pdf), sedangkan huruf besar Fmewakili fungsi distribusi kumulatif yang sesuai (cdf).
  • Juga dalam teori probabilitas, huruf besar menunjukkan variabel acak X, dan huruf kecil yang sesuai menunjukkan realisasi mereka x, seperti dalam $ Pr [X = x] \ leq 0,05 $.
  • Dalam aljabar linier, huruf besar biasanya digunakan untuk merujuk ke matriks sedangkan huruf kecil umumnya digunakan untuk merujuk ke angka, misalnya, $ A = [a_ {ij}] $.
  • Simbol satuan ditulis dalam huruf kecil (misalnya, m untuk meter) kecuali untuk liter (L) dan unit-unit tersebut berasal dari nama seseorang (W untuk Watt, Pa untuk Pascal, N untuk Newton, dan sebagainya).
  • Simbol awalan yang berarti satu juta atau lebih dikapitalisasi (M untuk mega (jutaan)), dan yang kurang dari satu juta adalah huruf kecil (m untuk mili (ribuan)).

3
Poin yang benar, tetapi Anda akan melanggar konvensi pengkodean dari hampir setiap bahasa pemrograman umum di luar sana, yang menggunakan sensitivitas huruf untuk tujuan mereka sendiri ..
Ken Bloom

3

Saya baru saja mengira itu karena Unix dan C - tapi itu semacam masalah ayam dan telur yang hanya bisa dijawab dengan baik oleh kakek tua.

Saya menggunakan alasan bahwa Ayam dalam "Kelinci Paskah Datang ke Kota" digunakan ketika ditanya apakah mereka datang sebelum Telur. Karena ada ayam di Bahtera Nuh, ayam lebih dulu. Oleh karena itu, karena GCC berjalan pada Unix, Unix datang pertama, karena itu karena Unix sangat peduli pada kasus, C dan semua varian dan turunannya, ya apa pun yang memaksakan kurung kurawal, peduli pada kasus.

Mungkin ada hubungan antara kurung kurawal dan sensitivitas case juga.


Unix datang bertahun-tahun sebelum GCC, tetapi kompiler BCPL asli datang sebelum Unix, dan umumnya menciptakan "sintaks C".
Ross Patterson

2

Selain jawaban luar biasa yang diberikan sejauh ini, saya ingin menunjukkan bahwa sensitivitas huruf memberi Anda juga "ruang nama" tambahan. Misalnya Perl memiliki beberapa blok khusus seperti BEGINdan ENDyang berjalan pada waktu yang berbeda dari kode normal (BEGIN pada waktu kompilasi, AKHIR setelah program normal dihentikan), dan menjadikannya sebagai huruf besar membuat semuanya menonjol, dan berarti huruf kecil varian bukan kata yang dipesan.

Seseorang dapat melangkah lebih jauh dan memesan semua huruf besar untuk penggunaan di masa depan oleh bahasa, dan tidak membahayakan programmer normal, yang biasanya TIDAK BERTEMU DALAM KODE MEREKA.


2

"Peka huruf besar kecil" selalu lebih baik bagi orang teknis untuk mengurangi ambiguitas. Ambil nama file sebagai contoh. Berurusan dengan nama file Windows lebih banyak masalah daripada nama file Unix karena nama file di Windows adalah case-sensitive sedangkan nama file di Unix adalah case-sensitive.

Kembali ke pemrograman. Untuk nama kelas, nama metode, nama variabel, sebagian besar bahasa tidak menerapkan aturan gaya penamaan. Terkadang demi kesederhanaan untuk melakukan "refleksi", kita dapat menggunakan nama "Case case" untuk mengikat ke sumber data lain tanpa konversi, atau menangani masalah dengan nama yang sama tetapi dalam kasus yang berbeda.


Omong kosong. Tampaknya hanya mengurangi ambiguitas karena Anda sudah mengharapkan perilaku case-sensitive.
Ross Patterson

1

Saya terkejut dengan kata-kata kasar ini. Sekarang tidak ada yang ingin Anda menggunakan garis bawah atau m_dalam nama bidang di C #, saya baru saja menggunakan kasing unta, dan jika nama bidang sama dengan nama properti publik, hanya saja nama properti publiknya adalah huruf Pascal dan bidang dukungan adalah kasus unta, saya pikir, "jadilah itu" - itulah yang tampaknya diinginkan oleh komunitas pemrograman. Sejauh ini belum ada masalah.


0

Terutama beberapa programmer berasal dari hari-hari awal BASIC, di mana nama variabel hanya bisa 2 karakter.

Jadi, ketika bisa sejumlah karakter, mereka menjadi sangat senang. Dan seiring dengan sensitivitas huruf - karena mereka tidak ingin juga peduli untuk SomeNamemenjadi sama secara tidak sengaja SOMENAMEdan menyebabkan bug karena hal-hal seperti ini.

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.