Haruskah Anda mengorbankan keterbacaan kode dengan seberapa efisien kode itu? [Tutup]

Haruskah Anda mengorbankan keterbacaan kode dengan seberapa efisien kode itu?

misal 3 baris kode menjadi 1 baris.

Saya membaca di Code Craft oleh Pete Goodliffe bahwa keterbacaan adalah kuncinya.

Pikiran Anda?

"Garis yang lebih sedikit" tidak selalu sama dengan "lebih efisien". Saya berasumsi maksud Anda "Haruskah program dibuat lebih pendek dengan mengorbankan keterbacaan".

Program harus ditulis untuk dibaca orang, dan hanya secara kebetulan untuk dijalankan mesin.

-Abelson & Sussman, Struktur dan Interpretasi Program Komputer

Secara umum, saya pikir lebih penting bahwa sebuah program mudah dipahami daripada singkat. Saya harus mencatat, bahwa membuat program lebih pendek sering juga membuatnya lebih mudah dibaca (ada ambang yang jelas Anda dapatkan ketika kode Anda mulai terlihat seperti derau baris, tetapi sampai saat itu, mengekspresikan sesuatu yang lebih ringkas tampaknya membuatnya lebih jelas).

Ada pengecualian khusus (seperti skrip shell pribadi Anda, atau satu kode data hijau) yang tidak perlu dipelihara oleh siapa pun, dan hanya Anda yang perlu membaca. Dalam situasi itu, mungkin tidak apa-apa mengorbankan beberapa keterbacaan untuk kepentingan selama Anda masih bisa memahaminya.

Terkadang ya.

Keterbacaan adalah hal yang baik untuk diperjuangkan. Sebagian besar kode yang ditulis untuk aplikasi lini bisnis biasa akan cukup performan dan fokus pada keterbacaan adalah penting. Di area yang lebih menuntut kinerja (seperti pemrograman video game atau perhitungan berat), mungkin penting untuk melupakan keterbacaan karena menggunakan fitur bahasa tertentu yang sangat tidak dapat dibaca dan sangat luar biasa performanya.

Untuk contoh yang terakhir, lihat artikel Fast Inverse Square Root di Wikipedia.

Saya biasanya berpikir bahwa lebih baik membuat sesuatu yang dapat dibaca terlebih dahulu dan khawatir tentang kinerja setelahnya, asalkan tindakan pencegahan yang masuk akal seperti tidak memilih algoritma O (n ^ 2) di atas O (n) diambil. Keterbacaan pengorbanan demi singkatnya saja, dalam pikiran saya, salah arah.

Satu-satunya waktu saya akan mengorbankan keterbacaan akan ketika kode ditampilkan sebagai hambatan kinerja dan penulisan ulang akan memperbaikinya. Dalam hal ini niat kode harus didokumentasikan dengan baik sehingga jika ada bug dapat dilacak dengan lebih mudah.

Itu tidak mengatakan bahwa penulisan ulang tentu saja tidak dapat dibaca.

Saya mengutipnya sebelumnya , dan saya akan mengutipnya lagi:

Buat itu benar,
jelaskan,
buat singkat,
cepat.

Dalam urutan itu.

Wes Dyer

Haruskah Anda mengorbankan keterbacaan kode dengan seberapa efisien kode itu?

Dalam hal kode, selalu menyenangkan untuk mendokumentasikan diri sendiri. Tetapi kadang-kadang itu tidak bisa terjadi. Terkadang Anda memang perlu mengoptimalkan dan terkadang kode itu sendiri tidak mudah dibaca.

Untuk itulah komentar diciptakan . Gunakan itu. Bahkan majelis memiliki komentar. Jika Anda telah menulis banyak kode dan tidak ada komentar yang terlihat, saya khawatir. Komentar tidak memengaruhi kinerja waktu berjalan, tetapi beberapa catatan tentang apa yang terjadi selalu membantu.

Dalam pikiran saya, sama sekali tidak ada alasan untuk tidak memiliki beberapa komentar dasar. Jelas if ( x == 0 ) /* check if x is 0 */sama sekali tidak berguna; Anda seharusnya tidak menambahkan suara yang tidak perlu ke kode, tetapi sesuatu seperti ini:

; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
    push rdp
    ; ...

Cukup membantu.

Haruskah Anda mengorbankan keterbacaan kode dengan seberapa efisien kode itu?

Jika efisiensi adalah tujuan Anda saat ini (seperti dalam fase optimasi) dan Anda tahu - Anda memiliki metrik, bukan? - baris kode itu adalah bottleneck saat ini, lalu ya.

Jika tidak, tidak: keterbacaan akan memungkinkan Anda (atau yang lain) untuk dapat mengubah kode ini nanti agar lebih efisien, karena lebih mudah dipahami.

Tidak ada yang memenangkan Code Golf

misal 3 baris kode menjadi 1 baris

Ide yang sangat mengerikan.

Biaya bermain golf kode - sangat tinggi.

Biaya untuk mempertahankan program yang tidak terbaca - astronomi.

Nilai kode diminimalkan semacam ini - nol. Masih berfungsi, tetapi tidak berfungsi "lebih baik".

Efisiensi yang Dipilih dengan Bijak

Biaya untuk memilih algoritma dan struktur data yang tepat - sedang.

Biaya untuk mempertahankan algoritma dan struktur data yang tepat - rendah.

Nilai algoritma yang tepat dan struktur data - tinggi. Penggunaan sumber daya rendah.

Efisiensi Bodoh ("optimasi mikro")

Biaya untuk bermain-main dengan optimalisasi mikro - tinggi.

Biaya untuk mempertahankan kode yang dioptimalkan untuk mikro yang tidak dapat dibaca - sangat tinggi.

Nilai optimalisasi mikro - bervariasi. Ketika ada nilai non-nol di sini, biaya masih lebih besar daripada itu.

Tergantung pada apakah kita berbicara tentang efisiensi dalam hal seberapa cepat kode dijalankan atau efisiensi dalam seberapa cepat pengembang dapat menulis kode. Jika Anda mengorbankan keterbacaan kode demi bisa mengetikkan kode dengan sangat cepat, Anda mungkin akan menemukan diri Anda membayar waktu mundur dalam hal debugging.

Namun, jika kita berbicara tentang pengorbanan pembacaan kode dalam hal seberapa cepat kode tersebut dieksekusi, maka itu kemungkinan merupakan trade off yang dapat diterima selama kode tersebut harus dibentuk sebelumnya secara efisien. Menulis sesuatu yang berjalan secepat mungkin hanya karena Anda bisa tidak sebagus dari alasan seperti karena itu adalah sesuatu seperti cepat terbalik akar kuadrat di mana kinerja adalah kunci. Kuncinya adalah antara menyeimbangkan kode dan memastikan bahwa meskipun sumbernya mungkin sulit dibaca, komentar yang menjelaskan apa yang dilakukannya menjelaskan apa yang sedang terjadi.

Banyak trik, yang seharusnya membuat kode lebih cepat, tetapi cenderung membuat kode kurang mudah dibaca, tidak diperlukan lagi, karena salah satu kompiler menjadi sangat pintar (bahkan lebih pintar dari kebanyakan pengembang) atau mesin menjadi cepat konyol.

Saya tidak menerima argumen "keterbacaan atas kinerja". Biarkan saya memberi Anda jawaban dengan putaran berbeda di atasnya.

Beberapa latar belakang: Anda tahu apa yang membuat saya sakit? Ketika saya mengklik dua kali pada Komputer Saya dan saya benar-benar harus menunggu untuk mengisi. Jika itu membutuhkan waktu lebih dari 5 detik, saya benar-benar frustrasi. Hal yang bodoh adalah, dan jangan hanya menyalahkan Microsoft untuk ini, adalah bahwa dalam beberapa kasus alasan untuk mengambil begitu lama adalah bahwa keputusan harus dibuat pada ikon apa yang harus ditampilkan! Betul sekali. Jadi di sini saya duduk, hanya tertarik untuk pergi ke drive C: saya, dan saya harus menunggu driver untuk mengakses CD-ROM saya dan membaca ikon dari sana (dengan asumsi ada CD di drive).

BAIK. Jadi sesaat bayangkan semua lapisan antara saya mengklik dua kali pada Komputer Saya dan itu benar-benar berbicara melalui driver ke CD-ROM. Sekarang bayangkan setiap lapisan ... lebih cepat ...

Anda lihat, di balik semua ini ada ribuan programmer yang senang karena kode mereka "lebih mudah dibaca". Itu keren. Aku bahagia untukmu Tapi dari perspektif pengguna itu hanya menyebalkan (istilah teknis). Jadi, Anda tidur nyenyak di malam hari mengatakan pada diri sendiri bahwa Anda melakukan hal yang benar dengan memastikan kode lebih mudah dibaca namun lebih lambat. Bahkan sedikit lebih lambat dari yang seharusnya. Dan ribuan pengembang melakukan ini, dan kami akhirnya menunggu PC kami karena Anda. Menurut saya kamu tidak layak. Saya tidak mengatakan kalimat pertama Anda perlu yang terbaik.

Inilah pendekatan saya: Pertama, buat itu bekerja, kemudian buatlah lebih cepat. Selalu bertujuan untuk menulis kode yang efisien dan jika Anda harus mengorbankan keterbacaan, tambahkan dengan komentar. Saya tidak akan mengorbankan efisiensi sehingga beberapa programmer yang biasa-biasa saja dapat mempertahankannya. Namun saya akan menjelaskan kode saya, tetapi jika itu tidak cukup, saya minta maaf, Anda benar-benar tidak kompeten untuk bekerja di sini. Karena di sini, kita menulis kode yang cepat dan dapat dibaca, dan meskipun ada keseimbangan, kode yang dapat dibaca dapat dijelaskan sedangkan inefisiensi hanya tidak dapat diterima.

Pertanyaan ini sering muncul di benak saya ketika wawancara dibahas di kantor. Bertahun-tahun yang lalu sebagai lulusan, saya ditanya pertanyaan "Apakah Anda pikir kode itu mendokumentasikan diri?". Sekarang, saya harus menjawab pertanyaan ini sebagai programmer dan sejauh menyangkut pewawancara, itu adalah pertanyaan hitam dan putih, jadi tidak ada jalan tengah. Prosesnya harus hidup lebih lama dari indivdual karena orang akan datang dan pergi lebih dari hidup dan Anda ingin mendapatkan awal yang baru siap sesegera mungkin, dan semakin mudah kode dibaca, semakin cepat memahami apa yang sedang terjadi.

Saya membaca sebuah buku beberapa waktu lalu yang cukup bagus, yang disebut Domain Driven Development: Domain-driven Design: Mengatasi Kompleksitas di Jantung Perangkat Lunak Harus diakui, ini sedikit kering pada awalnya, tetapi bahannya disajikan dengan baik. Ini menunjukkan pendekatan yang bagus yang mengarah ke sistem yang mendokumentasikan diri mereka dengan baik. Bahasa adalah media untuk mengkomunikasikan solusi Anda, jadi semakin jelas solusinya diungkapkan, semakin mudah untuk beradaptasi jika kinerja memang menjadi faktor utama. Itu keyakinan saya dan tampaknya berhasil dengan baik bagi saya.

Jarang ROI membuat kode berjalan lebih cepat dengan mengorbankan keterbacaan tidak sia-sia. Komputer modern berjalan sangat cepat sehingga saya ragu akan ada skenario di mana Anda menginginkan ini. Jika komputer menjalankan kode, kode itu perlu dipertahankan.

Untuk itu, saya menemukan keterbacaan sangat penting. Tentu saja, seperti yang dinyatakan berkali-kali, hanya karena kode dapat dibaca tidak perlu berarti lebih lambat.

Contoh yang baik adalah nama variabel: $a

Apa $a?? Ini di luar konteks sehingga Anda tidak bisa menjawabnya tetapi apakah Anda pernah mengalami ini dalam kode aktual? Sekarang anggap seseorang menulis $file_handle- sekarang apa itu? Sudah jelas bahkan di luar konteks. Panjang nama variabel membuat perbedaan yang tidak signifikan ke komputer.

Saya pikir ada akal sehat yang bisa didapat di sini.

Beberapa aplikasi mungkin memerlukan jalan pintas bit-shift yang tidak semua akan mengerti tetapi saya berpikir bahwa pada beberapa titik ada pengembalian berkurang dan menemukan skenario jarang *.

* ini tergantung pada industri dan hal-hal lain semacam itu. Saya melihat ini dari perspektif pengembang perangkat lunak bisnis (Sistem Informasi Bisnis).

Untuk melihat ini dari sudut pandang lain (tetapi tidak untuk mengoceh), saya bekerja di sebuah perusahaan yang melakukan SAAS. Ketika sebuah situs turun, kita harus memperbaikinya dengan sangat, sangat cepat - biasanya orang lain memperbaiki kode pengembang lain.

Saya lebih suka seseorang melakukan sesuatu yang sangat tidak efisien tetapi dapat dibaca daripada membuatnya mewah dan "cepat". Server web kami canggih dan permintaan tidak perlu dikirim dalam sepersejuta detik. Kami tidak memiliki masalah pemuatan.

Jadi, dalam praktiknya saya pikir Anda lebih cenderung menyakiti diri sendiri atau orang lain ... (Saya lebih suka memiliki akhir pekan saya kembali.)

Untuk sebagian besar setiap kasus, jawabannya adalah "Percayai kompiler Anda untuk melakukan tugasnya", dan tulis kode yang dapat dibaca. Ini menyiratkan bahwa kode terstruktur secara logis (yaitu, tidak ada spageti) dan dokumentasi sendiri (yaitu, cukup jelas nama variabel, fungsi, dll). Kode tambahan yang tidak didokumentasikan sendiri dengan komentar yang bermakna. Jangan berkomentar demi berkomentar, yaitu,

x++; // Add one to x

Sebaliknya, beri komentar untuk Anda, pembaca, dalam 6 bulan atau 12 bulan atau waktu lain yang cukup panjang. Adopsi standar pengkodean, dan ikuti.

Kode bersih adalah kode cepat. Ditulis dengan jelas, kode yang mudah dipelihara cenderung lebih cepat karena merupakan indikator bahwa pemrogram memahami tugas yang dihadapi, dan mere-refraktekan kode ke tujuan intinya.

Selain itu, kompiler modern mengoptimalkan instruksi dengan sangat efektif. Berapa banyak baris kode yang Anda ketikkan untuk melakukan sesuatu dan apa yang dibuat oleh kompiler dalam hal instruksi belum tentu terkait. Baca di kompiler untuk memahami mengapa itu terjadi.

Ketika saya mengerjakan sesuatu yang berbasis kinerja seperti grafik, saya kadang-kadang akan mengorbankan keterbacaan / pemeliharaan saat saya melakukan hal-hal seperti pemrosesan gambar ketika saya bekerja pada algoritma nested terdalam di mana optimasi kecil dapat memiliki efek besar. Dan bahkan kemudian saya hanya melakukannya setelah membuat profil untuk memastikan perubahan benar-benar mempercepat. Saya tidak bisa memberi tahu Anda berapa kali saya sudah mencoba 'optimasi' kode tangan hanya untuk menemukan bahwa itu benar-benar memperlambat aplikasi karena cara kompiler mengoptimalkan kode yang diketik tangan.

Keterbacaan adalah alasan bagi programmer yang tidak kompeten & malas (sebenarnya hal yang sama berlaku untuk "kesederhanaan" bila digunakan sebagai argumen untuk mempertahankan algoritma / desain jelek)!

Untuk setiap masalah Anda harus berusaha untuk solusi optimal! Fakta bahwa komputer saat ini cepat bukan alasan untuk membuang siklus CPU. Satu-satunya kendala adalah "waktu untuk menyampaikan". Perhatikan bahwa "solusi optimal" di sini berarti yang ANDA dapat hasilkan (kita semua tidak dapat menemukan solusi terbaik; atau memiliki keterampilan / pengetahuan untuk mengimplementasikannya).

Seperti yang disebutkan orang lain jika ada aspek "sulit untuk dipahami" dari suatu solusi, itulah gunanya komentar. Urutan "benar, mudah dibaca, cepat" (atau sesuatu seperti itu), yang orang lain sebutkan hanyalah buang-buang waktu.

Saya memiliki waktu yang sangat sulit untuk percaya bahwa ada programmer di luar sana, yang ketika dihadapkan dengan masalah yang mereka pikirkan di baris "... ini harus dilakukan seperti ini tetapi saya akan membuat cara yang kurang efisien tetapi lebih mudah dibaca / sampah yang bisa dirawat dan sejenisnya ... ". Kekeliruan dari ini adalah, bahwa pengembang berikutnya (melihat inefisiensi) kemungkinan besar akan memodifikasi kode dan selanjutnya akan melakukan hal yang sama dan seterusnya ... Hasil akhirnya adalah bahwa setelah beberapa versi kode akan menjadi seperti aslinya pengembang seharusnya menulis di tempat 1. Satu-satunya alasan untuk pengembang asli adalah a. dia tidak memikirkannya (cukup adil) dan (sebagaimana disebutkan sebelumnya) b. kendala waktu & sumber daya.

jika mengurangi keterbacaan membantu kinerja kode / optimisasi (seperti pada swfobject dan perpustakaan js lainnya) itu adalah alasan untuk terus menulis kode yang diformat dengan baik dan dapat dibaca dengan jelas dan mengubahnya menjadi tidak dapat dibaca / dioptimalkan sebagai bagian dari proses "kompilasi" / rilis.