Kenapa penamaan variabel menentukan kualitas kode
Bukan soal selera. Nama adalah satu-satunya dokumentasi yang pasti dibaca — karena ia ada di setiap baris yang disentuh orang berikutnya. Komentar basi, README basi, tiket Jira hilang. Nama tinggal.
Masalah nyata: nama buruk = biaya
Kode dibaca 10x lebih sering daripada ditulis. Setiap nama ambigu maksa pembaca menyimpan konteks di kepala — dan itu beban kognitif yang numpuk.
Contoh nyata yang sering ketemu:
// nama bilang "data", isinya apa? pembaca harus baca 40 baris ke bawah
const data = await fetch(url);
processData(data, true, false);
Dua masalah di 3 baris:
- data → nol informasi
- true, false → boolean blindness, pembaca harus buka signature buat tau parameter mana apa
Versi sama, biaya baca ~0:
const activeUsers = await fetchActiveUsers(tenantId);
purgeInactive(activeUsers, { dryRun: true, notifyOwner: false });
Diff-nya sama panjang. Informasi yang dibawa beda jauh.
Checklist nama (pakai saat review, 10 detik per nama)
| Cek | Pertanyaan | Gagal kalau... |
|---|---|---|
| Niat | Nama jawab "untuk apa", bukan "tipe apa"? | userList (tipe) vs pendingApprovers (niat) |
| Satuan | Kalau angka, satuannya jelas? | timeout, latency, size tanpa unit |
| Domain | Pakai istilah yang dipakai bisnis/user? | obj, item, entity padahal itu "invoice" |
| Panjang | Panjang proporsional scope? | i, x di 200 baris; theUserObjectThatWeFetched di loop 3 baris |
| Bisa diucap | Bisa dibaca di code review tanpa eja? | usrAccntMgrCfg |
| Konsisten | Satu konsep = satu kata di seluruh repo? | fetch / get / load / retrieve campur |
Aturan kasar: scope makin luas, nama makin panjang. Variabel loop i sah. Variabel modul i pidana.
Tiga jebakan yang paling mahal
1. Encoding tipe ke nama
strName, arrUsers, bIsActive (Hungarian notation). Bahasa modern sudah punya tipe. Yang berubah tipe saat refactor bikin nama jadi bohong — dan nama bohong lebih buruk dari nama generik. Pengecualian jujur: rawBytes vs decodedText — di situ tipenya memang bagian dari makna.
2. Nama yang bohong
users = get_active_users() # lalu di bawah: users += get_banned_users()
Semua pembaca berikutnya salah paham. Kalau isi berubah makna, ganti namanya di commit yang sama. Nama menyesatkan itu bug yang menular.
3. Boolean tanpa konteks
isValid, flag, enabled — valid untuk apa? enabled kapan?
# jelek
if (valid && enabled) { ... }
# jelas
if (invoice.isTaxCompliant && tenant.billingEnabled) { ... }
Prefer predikat positif (isVisible) daripada negasi ganda (isNotHidden → !isNotHidden bikin otak muter).
Satu hal yang bisa langsung dipakai
Latihan rename 60 detik — buka satu file yang kamu tulis minggu lalu, cari 3 nama terburuk, tulis versi barunya di komentar // TODO rename: tanpa langsung refactor. Kalau setelah seminggu nama baru masih terasa lebih benar, rename pakai tool refactor (bukan find-replace). Ini murah, aman, dan melatih insting penamaan tanpa nyentuh behavior.
Bonus: di code review, komentar paling berguna sering bukan "ini bug", tapi "data ini apa?" — kalau reviewer harus tanya, nama sudah gagal.
Takeaway
Nama yang baik bikin komentar jadi mubazir. Nama yang buruk bikin komentar jadi wajib — dan komentar itu bakal basi.
Kalau bingung kasih nama, biasanya tandanya fungsimu ngelakuin lebih dari satu hal. Pecah dulu, baru kasih nama.