Nama panjang terlalu panjang

Halo, Habr! Saya sajikan kepada Anda terjemahan artikel "Long Names Are Long" oleh Bob Nystrom.

Salah satu hal cerdas yang dilakukan Google adalah tinjauan kode yang ketat. Setiap perubahan, sebelum Anda diizinkan untuk sampai ke cabang utama, dianggap setidaknya dalam dua arah. Pertama, seseorang dalam tim melakukan pemeriksaan rutin untuk memastikan kode melakukan apa yang seharusnya.

Tetapi kemudian langkah kedua terjadi, ketika keterbacaan kode diperiksa. Ini memastikan bahwa pengembang lain akan dapat mendukung kode ini di masa mendatang. Apakah kode ini mudah dimengerti dan dipelihara? Apakah kode ini cocok dengan gaya dan idiom bahasa? Apakah kode didokumentasikan dengan baik?

Penggunaan bahasa Dart di Google secara bertahap mendapatkan momentum, dan saya banyak berurusan dengan ulasan kode tersebut. Untuk pengembang bahasa, ini adalah proses yang sangat menarik. Saya mendapatkan pandangan langsung tentang bagaimana orang menggunakan Dart, yang sangat berguna untuk pengembangannya. Saya memiliki gagasan yang lebih jelas tentang kesalahan mana yang umum dan fungsi mana yang banyak digunakan. Saya merasa seperti ahli etnografi, buku harian tentang kehidupan penduduk asli.

Tetapi, bagaimanapun juga, ini bukan masalahnya. Sialan dia, itu bahkan bukan Dart. Yang ingin saya bicarakan adalah apa yang saya lihat di banyak kode, dan yang membuat saya gila: nama yang terlalu panjang .

Ya, nama mungkin terlalu pendek. Pada hari-hari ketika C menuntut agar hanya pengidentifikasi eksternal yang unik hingga enam karakter pertama; ketika pelengkapan otomatis belum ditemukan; ketika setiap keystroke seperti memanjat menanjak melalui salju - ini adalah masalah. Saya senang bahwa kita sekarang hidup dalam utopia futuristik di mana keyboard kentut seperti p , idxcrpm dan x3 jarang terjadi.

Tapi pendulum itu berayun terlalu jauh ke arah lain. Kita tidak harus menjadi Hemingway, kita juga tidak perlu menjadi Tennessee Williams. Nama yang terlalu panjang juga merusak kejelasan kode di mana mereka digunakan. Nama variabel yang sangat panjang menaungi operasi yang Anda lakukan padanya. Kode menjadi sulit untuk dipindai secara visual. Untuk memenuhi persyaratan lebar kode, muncul jeda baris tambahan yang mengganggu aliran logis kode. Nama metode panjang menyembunyikan daftar argumen yang sama pentingnya. Variabel panjang mengganggu dari penggunaan kembali, yang mengarah ke peregangan rantai metode atau kaskade.

Saya melihat nama variabel lebih dari 60 karakter. Anda dapat meletakkan haiku atau koan di sana (dan mungkin mencerahkan pembaca lebih dari nama yang Anda pilih). Tapi jangan takut, saya di sini untuk membantu.

Memilih Nama Baik

Setiap nama dalam pemrograman memiliki dua tujuan:

• Nama harus jelas : Anda perlu tahu apa yang dimaksud.
• Nama harus akurat : Anda perlu tahu apa itu tidak berlaku.

Setelah namanya mencapai tujuan ini, karakter tambahan apa pun akan mati. Berikut adalah beberapa panduan yang saya gunakan ketika saya menyebutkan beberapa hal dalam kode saya:

1. Hindari kata-kata yang secara eksplisit ditentukan dalam tipe variabel atau parameter

Jika bahasa Anda memiliki sistem tipe statis, maka pengguna biasanya tahu jenis variabelnya. Sebagai aturan, metode cukup pendek, sehingga bahkan melihat variabel lokal di mana jenisnya tidak dapat langsung diasumsikan, atau pada tinjauan kode, atau di suatu tempat di mana analisis kode statis tidak dapat masuk - jarang perlu sedikit lebih banyak daripada melihat beberapa baris di atas untuk menentukan jenis variabel.

Mengingat hal ini, tidak perlu menunjukkan tipe dalam nama variabel. Kami baru saja meninggalkan notasi Hongaria . Lepaskan dan lupakan :

 // : String nameString; DockableModelessWindow dockableModelessWindow; // : String name; DockableModelessWindow window; 

Khususnya untuk koleksi, hampir selalu lebih baik menggunakan kata benda jamak yang menggambarkan konten daripada kata benda tunggal yang menggambarkan koleksi . Jika pembaca lebih peduli tentang apa yang ada dalam koleksi, maka judulnya harus mencerminkan itu.

 // : List<DateTime> holidayDateList; Map<Employee, Role> employeeRoleHashMap; // : List<DateTime> holidays; Map<Employee, Role> employeeRoles; 

Ini juga berlaku untuk nama metode. Nama metode tidak perlu menjelaskan parameternya atau tipenya - daftar parameter akan melakukannya untuk Anda.

 // : mergeTableCells(List<TableCell> cells) sortEventsUsingComparator(List<Event> events, Comparator<Event> comparator) // : merge(List<TableCell> cells) sort(List<Event> events, Comparator<Event> comparator) 

Ini menghasilkan panggilan yang dibaca lebih baik dari ini:

 mergeTableCells(tableCells); sortEventsUsingComparator(events, comparator); 

Apakah hanya saya, atau ada gema-gema di sini?

2. Hindari kata-kata yang tidak membingungkan nama

Beberapa orang cenderung mendorong segala sesuatu yang mereka ketahui tentang sesuatu menjadi nama variabel. Ingat bahwa nama itu adalah pengidentifikasi : itu menunjukkan tempat di mana ia didefinisikan. Ini bukan katalog lengkap segala sesuatu yang pembaca mungkin ingin tahu tentang objek. Definisi akan membuatnya lebih baik. Nama itu hanya akan mengarahkannya ke sana.

Ketika saya melihat namanya sebagai recentlyUpdatedAnnualSalesBid - recentlyUpdatedAnnualSalesBid , saya bertanya pada diri sendiri:

• Apakah ada pesanan penjualan tahunan yang diperbarui yang bukan yang terbaru?
• Apakah ada permintaan penjualan tahunan terbaru yang belum diperbarui?
• Apakah ada aplikasi non-penjualan tahunan yang baru saja diperbarui?
• Apakah ada data penjualan tahunan yang diperbarui baru-baru ini yang bukan penawaran?

Jika jawabannya “tidak” untuk setidaknya satu dari pertanyaan ini, maka ini biasanya menunjukkan kata tambahan dalam namanya.

 // : finalBattleMostDangerousBossMonster; weaklingFirstEncounterMonster; // : boss; firstMonster; 

Tentu saja, Anda mungkin melangkah terlalu jauh. Memperpendek contoh pertama untuk bid mungkin terlalu samar. Tetapi jika ragu, biarkan saja seperti itu. Anda selalu dapat menambahkan klasifikasi tambahan nanti jika nama adalah penyebab konflik atau tidak akurat. Namun, kecil kemungkinan Anda akan kembali lagi nanti untuk memangkas semua kelebihan lemak ini.

3. Hindari kata-kata yang jelas dari konteksnya.

Saya dapat menggunakan kata "Saya" dalam paragraf ini karena Anda tahu bahwa teks ini dari Bob Nystrom. Saya tidak perlu terus-menerus mengulangi "Bob Nystrom" di sini (terlepas dari godaan Bob Nystrom untuk memperkuat Bob Nystrom dengan cara ini). Kode kerjanya persis sama. Metode atau bidang terjadi dalam konteks kelas. Variabel terjadi dalam konteks suatu metode. Terima konteks ini begitu saja dan jangan ulanginya.

 // : class AnnualHolidaySale { int _annualSaleRebate; void promoteHolidaySale() { ... } } // : class AnnualHolidaySale { int _rebate; void promote() { ... } } 

Dalam praktiknya, ini berarti bahwa semakin dalam nama itu tertanam, semakin banyak konteks yang dimilikinya. Hasilnya, ternyata nama ini akan lebih pendek. Sebagai hasilnya, Anda dapat melihat pola: pengidentifikasi yang berada di area yang lebih sempit memiliki nama yang lebih pendek.

4. Hindari kata-kata yang tidak ada artinya.

Saya sering melihat kesalahan ini di industri game. Beberapa pengembang menyerah pada godaan dan mengembang nama-nama variabel mereka, menambahkan kata-kata dari "bisnis serius". Mereka percaya bahwa ini membuat kode mereka lebih penting dan, karenanya, membuat mereka lebih penting.

Dalam kebanyakan kasus, kata-kata ini tidak membawa informasi yang berarti bagi pengembang. Biasanya, kecurigaan jatuh pada kata-kata seperti: data , state , amount , value , manager , engine , object , entity dan instance .

Nama yang bagus melukiskan gambaran di benak pembaca. Menyebut apa pun sebagai "manajer," kami tidak memberikan informasi apa pun kepada pembaca tentang apa yang harus dilakukan objek ini. Apakah ini melakukan perhitungan penilaian kinerja? Menunjuk promosi ke karyawan mereka?

Tanyakan kepada diri sendiri: "Apakah nama ini akan berarti sama jika saya mengambil kata itu?" Jika ya, maka kata itu tidak masalah - mengusir dari pulau.

Menerapkan manual ke ... wafel

Untuk memberi Anda gambaran tentang bagaimana aturan ini bekerja dalam praktiknya, berikut adalah contoh yang melanggar semuanya. Contoh yang dibuat-buat ini sangat mirip dengan kode asli, yang cukup sering saya temui pada ulasan kode.

 class DeliciousBelgianWaffleObject { void garnishDeliciousBelgianWaffleWithStrawberryList( List<Strawberry> strawberryList) { ... } } 

Berkat jenis parameter, kita tahu bahwa metode menerima daftar stroberi (# 1). Mari kita hilangkan info ini dari sebuah nama:

 class DeliciousBelgianWaffleObject { void garnishDeliciousBelgianWaffle( List<Strawberry> strawberries) { ... } } 

Jika tidak ada wafel Belgia hambar atau wafel dari negara lain dalam program ini, maka kami dapat dengan aman membuang semua kata sifat (# 2):

 class WaffleObject { void garnishWaffle(List<Strawberry> strawberries) { ... } } 

Metode ini ada di dalam WaffleObject , jadi dari konteksnya kita tahu persis apa yang akan menghiasi (# 3):

 class WaffleObject { void garnish(List<Strawberry> strawberries) { ... } } 

Jelas ini adalah sebuah objek. Semuanya adalah objek dalam pemrograman berorientasi objek (# 4):

 class Waffle { void garnish(List<Strawberry> strawberries) { ... } } 

Sekarang jauh lebih baik.

Saya pikir ini adalah rekomendasi yang cukup sederhana. Anda memiliki hak untuk berpikir bahwa tidak ada gunanya khawatir tentang hal sepele seperti itu. Tetapi saya percaya bahwa penamaan adalah salah satu tugas paling mendasar yang kami lakukan saat pemrograman. Nama adalah struktur yang kita terapkan pada lautan bit tak berbentuk, yang merupakan komputer.