Mengapa tidak keduanya?
Pertama-tama, "deskriptif" dan "verbose" tidak sama. Misalnya, jika Anda menulis loop lokal, i
adalah nama variabel yang sangat bagus untuk variabel loop; current_iteration_index
, sementara bisa dibilang lebih deskriptif dan jelas lebih bertele-tele, jauh lebih buruk dan tidak menambahkan informasi sama sekali, karena penggunaan i
sebagai variabel loop cukup banyak diterima secara universal, dan tidak ada arti lain i
selain itu.
Nama variabel yang baik bersifat deskriptif, karena seorang programmer yang akrab dengan idiom bahasa dan konvensi basis kode dapat dengan mudah menebak apa peran mereka, tetapi mereka juga cukup ringkas untuk membuat segala sesuatunya tetap kompak.
Batas 80 karakter, walaupun awalnya merupakan konsekuensi dari keterbatasan teknis terminal teks tahun 1970-an, masih dihargai oleh banyak orang saat ini, dan meskipun masih ada alasan teknis (panjang garis maksimum dalam beberapa protokol jaringan, terutama terkait dengan e-mail), alasan yang lebih menarik adalah alasan psikologis dan sosial. Ternyata panjang garis di sekitar tanda 66 membuat pengalaman membaca yang paling nyaman untuk prosa bahasa alami (ukuran font yang menarik tidak membuat banyak perbedaan, dan akibatnya, tidak juga ukuran layar atau kertas); Batas garis 80 karakter cukup dekat dengan itu, tetapi karena sebagian besar potongan kode biasanya menjorok setidaknya satu atau dua level (yang berarti antara 4 dan 16 karakter, tergantung pada pengaturan lekukan),
Efek lain dari berpegang pada garis 80-karakter adalah bahwa itu adalah indikator yang cukup bagus ketika semuanya terlalu rumit. Garis yang panjang biasanya disebabkan oleh salah satu dari yang berikut:
- Fungsinya dengan daftar panjang argumen; ini bukan hal yang baik untuk dimiliki, karena mereka menghambat keterbacaan dan dapat dengan mudah menyebabkan bug halus, misalnya ketika orang bertukar urutan argumen dengan cara yang tidak ditangkap oleh kompiler.
- Ekspresi kompleks, sering ditemukan dalam kondisi (misalnya
if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)
); ini juga biasanya agak sulit untuk diuraikan, dan kode harus ditulis ulang menjadi sesuatu yang lebih terstruktur. Kemungkinan besar, ekspresi itu terlalu banyak dan harus difaktorkan ke dalam metode atau fungsi.
- Literal panjang yang digunakan dalam pemanggilan fungsi atau ekspresi, mis
print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));
. Pindahkan literal ke dalam variabel atau konstan; mungkin masih melebihi panjang garis, tetapi jika Anda melakukannya secara konsisten, pembaca setidaknya dapat dengan aman mengabaikan bagian garis yang tidak terlihat, dengan asumsi bahwa hanya sisa dari literal yang mengikuti. Atau lebih baik lagi, pindahkan literal keluar dari kode dan ke penyimpanan data eksternal (file, database, apa pun).
- Pernyataan yang sangat bersarang, misalnya enam tingkat
if
pernyataan dalam metode kelas (yaitu 32 kolom lekukan untuk pengaturan tipikal). Sekali lagi, sarang yang dalam membuat kode yang rumit dan sulit dibaca, dan harus dihindari seperti wabah - sederhananya, sarang yang dalam meluap dari tumpukan otak manusia saat membaca.
Semua ini pada akhirnya adalah gejala dari hal-hal yang Anda tidak akan miliki dalam basis kode Anda dalam jangka panjang, dan menegakkan batas 80 karakter adalah cara yang bagus dan sederhana yang membantu menjaga kompleksitas turun dan keterbacaan tetap tinggi. (Bukan berarti Anda tidak dapat menulis kode yang benar-benar tidak dapat dibaca dalam 80 kolom: berbagai kontes kode sesuatu yang membingungkan adalah contoh-contoh yang jelas).