Konverter Huruf

Jenis-jenis case dan tempat yang cocok

camelCase diawali huruf kecil dan setiap kata berikutnya diawali huruf besar; ini konvensi untuk variabel dan fungsi di JavaScript, Java, dan Swift. PascalCase juga mengawali kata pertama dengan huruf besar dan umumnya dipakai untuk tipe, kelas, dan komponen. snake_case menggabungkan kata berhuruf kecil dengan garis bawah dan menjadi standar di Python, Ruby, Rust, serta identifier SQL. SCREAMING_SNAKE_CASE sama tetapi berhuruf besar, dipakai hampir khusus untuk konstanta dan variabel lingkungan.

kebab-case menggabungkan kata berhuruf kecil dengan tanda hubung dan cocok di tempat yang garis bawahnya merepotkan atau tidak terlihat: slug URL, nama kelas dan custom property CSS, atribut HTML, flag baris perintah, nama paket npm. dot.case muncul di kunci konfigurasi dan pengaturan yang memakai namespace.

Memilih yang tepat jarang soal selera. Setiap ekosistem punya konvensinya, linter menegakkannya, dan identifier dengan case yang salah terasa asing di file tempatnya berada.

Memecah kata adalah bagian yang sulit

Mengubah case itu mudah setelah Anda tahu di mana kata-katanya, dan menemukan kata-kata itulah yang membuat implementasi naif tersandung. Input dipecah pada garis bawah, tanda hubung, titik, dan spasi, serta pada batas huruf besar-kecil, sehingga userName dan user_name menghasilkan dua kata yang sama.

Deretan huruf besar diperlakukan sebagai satu kata, bukan satu kata per huruf. XMLHttpRequest dipecah menjadi XML, Http, Request, menghasilkan xml_http_request, bukan x_m_l_http_request, dan getUserID tetap mempertahankan ID secara utuh. Aturannya, deretan huruf besar berakhir satu karakter sebelum huruf kecil yang mengikutinya, dan itulah yang membuat H pada Http memulai kata baru, bukan mengakhiri kata sebelumnya.

Angka menempel pada kata yang mendahuluinya, jadi parseInt32 dipecah menjadi parse, Int32. Pemisah di awal dan akhir dibuang, dan pemisah yang berulang digabung.

Case untuk tulisan, dan aksara CJK

Title Case bukan sekadar mengawali setiap kata dengan huruf besar. Panduan gaya bahasa Inggris mempertahankan huruf kecil untuk artikel, preposisi pendek, dan konjungsi koordinatif kecuali di awal atau akhir judul, itulah sebabnya hasilnya The Lord of the Rings, bukan The Lord Of The Rings. Panduan-panduan itu tidak sepakat soal batasnya, terutama untuk preposisi empat huruf atau lebih, jadi periksa panduan Anda jika hal ini penting. Sentence case hanya mengawali kata pertama dengan huruf besar dan membiarkan sisanya, dan makin sering dipakai sebagai gaya judul.

Bahasa Jepang, Mandarin, dan Korea sama sekali tidak mengenal huruf besar-kecil, jadi karakternya dilewatkan tanpa diubah. Pada teks campuran, hanya bagian beraksara Latin yang dikonversi. Deretan karakter CJK diperlakukan sebagai satu kata, karena memecahnya menjadi kata-kata memerlukan kamus dan segmenter, dan menebak batasnya hanya akan menghasilkan output yang salah dengan penuh keyakinan.

Konversi bolak-balik kehilangan informasi

Mengubah identifier ke case lain lalu mengembalikannya tidak selalu menghasilkan bentuk semula. snake_case ke camelCase dan kembali lagi aman, karena batas garis bawah tetap bertahan sebagai batas huruf besar-kecil. Tetapi apa pun yang melibatkan akronim tidak aman: HTTPServer menjadi http_server, dan dikembalikan menjadi HttpServer. Informasi bahwa HTTP adalah akronim hanya ada di huruf kapitalnya, dan hilang saat diubah ke huruf kecil.

Ini penting saat mengganti nama di seluruh basis kode, dan menjadi alasan untuk mengonversi sekali saja dari nama aslinya, bukan merangkai beberapa konversi.

Mengapa konvensinya bisa berbeda-beda

Tidak ada gaya di antaranya yang lebih baik dari yang lain; semuanya kebetulan sejarah yang mengeras menjadi standar komunitas. C dan keturunannya di Unix memilih huruf kecil dengan garis bawah karena linker awal tidak membedakan huruf besar-kecil dan nama panjang itu mahal. Smalltalk mempopulerkan camelCase, Java mewarisinya, dan JavaScript mengikuti Java cukup dekat sehingga mewarisinya sekali lagi.

Panduan gaya Python menetapkan snake_case untuk fungsi dan variabel serta PascalCase untuk kelas, dan kekuatan dokumen itulah yang membuat kode Python terlihat konsisten antarproyek, sesuatu yang tidak pernah dicapai bahasa-bahasa yang lebih tua. CSS dan HTML menetap pada kebab-case sebagian karena tata bahasanya tidak membedakan huruf besar-kecil dan sebagian karena tanda hubung terbaca alami di bahasa yang tidak punya identifier.

Konsekuensi praktisnya, case yang benar adalah case yang dipakai ekosistem di sekitarnya. File Python yang penuh camelCase lebih sulit dibaca bukan karena gayanya lebih buruk, melainkan karena ia memecah pola yang diikuti semua file lain di proyek itu.

Melintasi batas antara dua konvensi

Kebanyakan sistem nyata punya setidaknya satu sambungan tempat konvensinya berganti. Skema PostgreSQL memakai snake_case karena identifier tanpa tanda kutip diubah menjadi huruf kecil; API JSON di depannya biasanya memakai camelCase; komponen React yang mengonsumsi JSON itu memakai PascalCase untuk komponennya dan camelCase untuk props-nya; dan kelas CSS yang dirender berupa kebab-case.

Melakukan konversi di sambungan itu, di satu tempat saja, adalah yang membuat semuanya tetap terkendali. Hampir semua ORM dan pustaka serialisasi menyediakan pengaturan strategi penamaan justru untuk ini, dan memakainya jauh lebih baik daripada memetakan setiap field secara manual, yang menjadi sumber salah ketik dan properti yang hilang diam-diam.

Yang harus dihindari adalah mengonversi dua kali, atau mengonversi ke dua arah di lapisan yang berbeda. Ketika sebuah field tiba sebagai user_name, menjadi userName di klien, lalu dikirim kembali sebagai userName ke API yang mengharapkan user_name, ketidakcocokan itu biasanya muncul sebagai nilai yang diabaikan diam-diam, bukan sebagai error.

Mengganti nama di seluruh basis kode tanpa merusaknya

Penggantian nama hanya berupa cari-dan-ganti pada kasus yang paling sederhana. Identifier yang sama bisa muncul sebagai variabel, di dalam string yang dipakai untuk serialisasi, sebagai kolom database, di path URL, dan di dokumentasi, dan semua itu bukan perubahan yang sama - mengganti nama variabel itu aman, mengganti kunci yang diserialisasi adalah perubahan API yang merusak kompatibilitas.

Urutan yang berhasil adalah mengonversi sekali dari nama aslinya, bukan merangkai beberapa konversi, karena akronim tidak selamat dalam perjalanan bolak-balik: HTTPServer menjadi http_server dan kembali menjadi HttpServer. Buat seluruh pemetaannya lebih dulu, tinjau, lalu terapkan.

Linter adalah perbaikan yang bertahan lama. ESLint, Ruff, golint, dan sejenisnya bisa menegakkan konvensi penamaan pada kode baru, sehingga masalahnya tidak berulang setelah satu penggantian nama besar selesai.

Huruf besar-kecil tidak sederhana di semua bahasa

Mengubah ke huruf besar atau kecil adalah operasi yang bergantung pada locale, dan beberapa kasus terkenal merusak kode yang naif. Dalam bahasa Turki, huruf besar dari i memakai titik, dan mengecilkan I menghasilkan karakter tanpa titik - itulah sebabnya perbandingan tanpa memperhatikan huruf besar-kecil yang dijalankan di locale Turki bisa gagal mencocokkan identifier yang di bahasa Inggris terlihat identik. Pertahanan yang lazim adalah mengubah ke huruf kecil dengan locale invarian ketika teksnya adalah identifier, bukan kalimat biasa.

Huruf ß dalam bahasa Jerman menjadi SS saat dikapitalkan, sehingga operasinya mengubah panjang string, dan konversi bolak-balik tidak mengembalikan bentuk semula. Sigma Yunani punya dua bentuk huruf kecil tergantung apakah ia mengakhiri kata. Semua ini tidak memengaruhi identifier ASCII, yang mencakup sebagian besar kode, tetapi semuanya memengaruhi teks yang dimasukkan pengguna.

Konversi di sini bekerja pada teks Latin dan membiarkan karakter Jepang, Mandarin, dan Korea apa adanya, karena sistem tulisan itu sama sekali tidak mengenal huruf besar-kecil.

Penamaan adalah bagian yang hidup lebih lama dari kodenya

Konversi case bersifat mekanis; memilih katanya tidak, dan kata-kata itulah yang benar-benar menyulitkan pembaca. Gaya yang konsisten membuat basis kode terbaca sekilas, tetapi nama buruk yang diterapkan secara konsisten tetaplah nama buruk, dan mengganti nama itu murah sekarang dan mahal setelah identifier itu ada di API, kolom database, dan tiga dasbor.

Beberapa konvensi sepadan dengan usahanya. Boolean paling enak dibaca dengan awalan yang membuat pertanyaannya eksplisit - isActive, hasPermission, canEdit - karena active saja ambigu antara keadaan dan tindakan. Koleksi ditulis jamak dan item tunggal ditulis tunggal, jadi users dan user, bukan userList. Satuan ikut di dalam nama: timeoutMs, sizeBytes, priceCents.

Hindari menyingkat sampai tidak dikenali lagi. Dua huruf yang dihemat pada usrMgr membebani setiap pembaca berikutnya dengan satu jeda, dan pencarian menjadi tidak andal ketika separuh basis kode menulis user dan separuhnya lagi usr. Hal yang sama berlaku untuk sinonim yang tidak konsisten: fetch, get, load, dan retrieve mengerjakan hal yang sama di empat modul adalah pajak kecil yang dibayar selamanya, dan memilih salah satunya gratis.