Satu hal yang perlu diperhatikan adalah bahwa kode sering dibaca, untuk "kedalaman" yang berbeda. Kode ini:
PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc");
wakeLock.acquire();
mudah untuk "skim". Ada 3 pernyataan. Pertama kami datang dengan PowerManager
. Lalu kami datang dengan WakeLock
. Lalu kami acquire
yang wakeLock
. Saya bisa melihatnya dengan sangat mudah hanya dengan melihat awal setiap baris; tugas variabel sederhana benar-benar mudah dikenali sebagian sebagai "Ketik varName = ..." dan hanya skim mental atas "...". Demikian pula pernyataan terakhir jelas bukan bentuk penugasan, tetapi hanya melibatkan dua nama, sehingga "inti utama" segera terlihat. Seringkali hanya itu yang perlu saya ketahui jika saya hanya mencoba menjawab "apa yang dilakukan kode ini?" pada level agak tinggi.
Jika saya mengejar bug halus yang saya pikir ada di sini, maka jelas saya harus membahas ini lebih detail, dan akan benar-benar mengingat "...". Tetapi struktur pernyataan yang terpisah masih membantu saya melakukan pernyataan itu satu per satu (khususnya berguna jika saya perlu terjun lebih dalam ke dalam implementasi hal-hal yang dipanggil dalam setiap pernyataan; ketika saya kembali, saya sepenuhnya memahami "satu unit" dan kemudian dapat beralih ke pernyataan berikutnya).
((PowerManager)getSystemService(POWER_SERVICE))
.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag")
.acquire();
Sekarang semuanya satu pernyataan. Struktur tingkat atas tidak mudah dibaca skim; dalam versi asli OP, tanpa linebreak dan indentasi untuk secara visual mengkomunikasikan struktur apa pun, saya harus menghitung tanda kurung untuk menerjemahkannya ke dalam urutan 3 langkah. Jika beberapa ekspresi multi-bagian bersarang di dalam satu sama lain alih-alih diatur sebagai rangkaian panggilan metode, maka itu masih bisa terlihat mirip dengan ini, jadi saya harus berhati-hati mempercayai itu tanpa menghitung tanda kurung. Dan jika saya benar-benar memercayai indentasi dan hanya melihat ke depan ke hal terakhir sebagai titik yang diduga dari semua ini, apa yang .acquire()
saya katakan sendiri?
Namun terkadang, itu bisa menjadi apa yang Anda inginkan. Jika saya menerapkan transformasi Anda setengah jalan dan menulis:
WakeLock wakeLock =
((PowerManeger)getSystemService(POWER_SERVICE))
.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakeLockTage");
wakeLock.acquire();
Sekarang ini berkomunikasi dengan skim cepat "dapatkan WakeLock
, lalu acquire
itu". Bahkan lebih sederhana dari versi pertama. Segera jelas bahwa hal yang diperoleh adalah a WakeLock
. Jika memperoleh PowerManager
hanya sub-detail yang cukup signifikan untuk poin kode ini, tetapi yang wakeLock
penting, maka itu sebenarnya bisa membantu untuk mengubur PowerManager
barang - barang jadi wajar saja untuk melewatinya jika Anda hanya mencoba dengan cepat mendapatkan ide tentang apa kode ini. Dan tidak penamaan itu berkomunikasi bahwa itu adalah hanya digunakan sekali, dan kadang-kadang itu yang penting (jika sisa cakupannya sangat panjang, saya harus membaca semua itu untuk mengetahui apakah itu pernah digunakan lagi; meskipun menggunakan sub-lingkup eksplisit dapat menjadi cara lain untuk mengatasinya, jika bahasa Anda mendukungnya).
Yang memunculkan bahwa semuanya tergantung pada konteks dan apa yang ingin Anda komunikasikan. Seperti halnya menulis prosa dalam bahasa alami, selalu ada banyak cara untuk menulis sepotong kode tertentu yang pada dasarnya setara dalam hal konten informasi. Seperti halnya menulis prosa dalam bahasa alami, bagaimana Anda memilih di antara mereka umumnya tidak boleh menerapkan aturan mekanistik seperti "menghilangkan variabel lokal yang hanya terjadi sekali". Lebih tepatnya bagaimanaAnda memilih untuk menuliskan kode Anda akan menekankan hal-hal tertentu dan tidak menekankan yang lain. Anda harus berusaha keras untuk membuat pilihan-pilihan itu secara sadar (termasuk pilihan untuk menulis kode yang kurang mudah dibaca karena alasan teknis pada waktu tertentu), berdasarkan apa yang sebenarnya ingin Anda tekankan. Terutama pikirkan tentang apa yang akan melayani pembaca yang hanya perlu "mendapatkan intisari" dari kode Anda (di berbagai tingkatan), karena itu akan terjadi jauh lebih sering daripada pembacaan ekspresi-per-ekspresi yang sangat dekat.