it-swarm-id.com

Haruskah Anda mengorbankan keterbacaan kode dengan seberapa efisien kode itu?

Haruskah Anda mengorbankan keterbacaan kode dengan seberapa efisien kode itu?

misalnya 3 baris kode menjadi 1 baris.

Saya membaca Pembuatan Kode oleh Pete Goodliffe bahwa keterbacaan adalah kunci.

Pikiran Anda?

40
TeaDrinkingGeek

"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 kebijaksanaan selama Anda masih bisa memahaminya.

62
Inaimathi

Terkadang, ya.

Keterbacaan adalah hal yang baik untuk diperjuangkan. Kebanyakan 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 akal sehat seperti tidak memilih algoritma O (n ^ 2) lebih dari O(n) diambil. Mengorbankan keterbacaan demi singkatnya saja, dalam pikiran saya, salah arah.

30
Adam Lear

Saya mengutipnya sebelumnya , dan saya akan mengutipnya lagi:

Buat itu benar,
membuatnya jelas,
buat singkat,
membuatnya cepat.

Dalam urutan itu.

Wes Dyer

23
Benjol

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.

22
ChrisF

Haruskah Anda mengorbankan readbility 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.

Inilah komentar yang diciptakan untuk. 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.

9
user10197

Haruskah Anda mengorbankan readbility 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.

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

6
Klaim

Tidak ada yang memenangkan Code Golf

misalnya 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 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.

4
S.Lott

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. 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 baris pertama Anda harus menjadi yang terbaik.

Inilah pendekatan saya: Pertama, buat itu bekerja, kemudian buat lebih cepat.Selal 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.

2
Maltrap

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 tidak bisa sebagus alasan karena itu adalah sesuatu seperti akar kuadrat terbalik cepat di mana kinerja adalah kuncinya. Kuncinya adalah antara menyeimbangkan kode dan memastikan bahwa meskipun sumbernya mungkin sulit dibaca, komentar yang menjelaskan apa yang dijelaskannya menjelaskan apa yang sedang terjadi.

2
rjzii

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 buku beberapa waktu lalu yang cukup bagus, yang disebut Domain Driven Development: Desain berbasis domain: Mengatasi Kompleksitas di Jantung Perangkat Lunak Harus diakui, ini sedikit bacaan kering pada awalnya, tetapi materi 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.

2
Desolate Planet

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 konyol dengan cepat .

2

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 yang $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 tapi saya pikir bahwa pada beberapa titik ada pengembalian yang 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 akan banyak lebih suka seseorang melakukan sesuatu yang sangat tidak efisien tetapi dapat dibaca daripada membuatnya mewah dan "cepat". Server web kami sedang mutakhir 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.)

1
Frank V

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 (mis., Tidak ada spaghetti) dan dokumentasi sendiri (mis., Nama variabel, fungsi, dll.) Yang cukup jelas. Kode tambahan yang tidak didokumentasikan sendiri dengan komentar yang bermakna. Jangan berkomentar demi berkomentar, mis.,

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.

1
Throwback1986

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 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 sebenarnya mempercepat. Saya tidak bisa memberi tahu Anda berapa kali saya sudah mencoba kode tangan 'optimasi' hanya untuk menemukan bahwa itu sebenarnya memperlambat aplikasi karena cara kompiler mengoptimalkan kode yang diketik dengan tangan.

0
GrandmasterB