Apakah mungkin membuat kode panjang yang mewakili suatu komputasi lebih mudah dibaca?

9

Metode panjang umumnya dianggap buruk, namun dalam kode saya, saya memiliki beberapa metode panjang yang sulit dipahami (lebih dari 50 baris). Saya kesulitan membuat metode-metode itu lebih mudah dibaca karena satu pernyataan di dalamnya sudah lebih dari 50 baris, dan pernyataan tunggal yang sulit dibaca itu adalah untuk membangun kueri basis data menggunakan ORM untuk melakukan beberapa pekerjaan tertentu di mana pekerjaan dilakukan adalah ditunjukkan dengan jelas pada nama metode. Alasan mengapa pernyataan itu begitu panjang karena ia bergabung pada banyak kolom, menerapkan banyak wheres dan memilih beberapa kolom berbeda untuk membuat format output yang didokumentasikan yang diperlukan.

Apakah kode yang sulit dibaca itu dianggap sebagai kode yang buruk? Demikian pula, jika saya menulis kode untuk algoritma rumit yang menghasilkan kode yang sulit dibaca yang dibungkus dengan metode yang diberi nama jelas, apakah kode itu kode yang buruk?

readability

— Michael Tsang
sumber

Apakah tidak ada cara bagi Anda untuk parametrize kueri dalam beberapa cara? Saya menduga bahwa permintaan ini bervariasi tergantung pada apa yang terjadi di dalam metode yang dibuat. Mungkin Anda dapat memecahnya menjadi potongan-potongan kecil dan menyusunnya dalam beberapa langkah sehingga lebih mudah dibaca.

— Zalomon

Apakah ORM Anda mendukung tampilan? Anda dapat mengekstrak (grup) bergabung ke tampilan dan kemudian memilih tampilan. Bahkan jika itu pandangan tidak digunakan di tempat lain, itu dapat membantu memecah pernyataan SQL besar

— Caleth

Apakah ORM Anda mendukung bahasa query seperti SQL? Jika ya, Anda dapat memindahkan kueri ke file sendiri dan mengaktifkan penyorotan sintaksis IDE untuknya. Dalam aplikasi Anda memuat kueri dari file. Jika IDE Anda tidak benar-benar mendukung bahasa permintaan khusus itu, Anda mungkin bisa cocok dengan pemformatan SQL meskipun itu mungkin tidak sempurna. Namun keterbacaan sebagian besar meningkat oleh pemformatan yang baik. Ini juga memiliki manfaat yang mudah untuk menyalin kueri ke alas dan melakukan modifikasi di sana.

— SpaceTrucker

17

Kau menulis

Apakah kode yang sulit dibaca dianggap kode yang buruk

jadi Anda pasti setuju itu adalah kode yang sulit dibaca , dan jika sulit dibaca, sulit untuk mempertahankan dan berevolusi - jadi saya kira Anda menganggap kode tersebut sebagai "buruk" dengan ukuran Anda sendiri. Namun, kadang-kadang tidak jelas bagaimana meningkatkan sesuatu seperti pernyataan SQL 50 baris. Refactoring "ekstrak metode" yang mudah tidak berfungsi, dan Anda mungkin tidak tahu harus mulai dari mana dalam membuat kode lebih mudah dibaca. Untuk kasus ini, Anda masih dapat mencoba satu atau semua hal berikut ini

perlihatkan kode orang lain yang lebih berpengalaman dari Anda dalam membersihkan kode. Jika Anda tidak memiliki seseorang di organisasi Anda yang dapat Anda tanyakan, coba codereview.stackexchange
coba ke google untuk masalah spesifik. Sebagai contoh Anda, hal-hal seperti "membersihkan pernyataan sql panjang" mungkin merupakan awal yang baik. Anda akan heran betapa banyak artikel yang Anda temukan tentang topik itu, dan bahkan jika Anda tidak dapat menemukan resep braindead untuk kasus Anda, Anda mungkin mendapatkan beberapa ide segar
alih-alih meminta justifikasi untuk hal-hal yang tidak dapat Anda lakukan, fokuslah pada hal-hal yang dapat Anda lakukan untuk membersihkan kode setidaknya sedikit, seperti menambahkan jeda baris yang tepat, lekukan yang tepat, menambahkan beberapa komentar yang menjelaskan, memberikan beberapa variabel lebih baik nama. Bukan tidak mungkin, selama proses ini, memaksa diri Anda untuk membaca kembali detail kode, Anda menemukan cara untuk mengubah kode menjadi unit yang lebih kecil
latihan, latihan, latihan. "Clean coding" bukanlah sesuatu yang Anda pelajari dalam satu hari, itu menjadi lebih mudah dengan lebih banyak pengalaman. Mungkin Anda tidak menemukan solusi untuk masalah Anda hari ini, tetapi ketika Anda kembali ke kode dalam beberapa bulan, itu akan terlihat berbeda bagi Anda.

— Doc Brown
sumber

Saya agak tidak setuju dengan bagian komentar, jika ada satu bagian kompleks dari kode yang kompleks karena tidak bisa sebaliknya DAN tidak menemukan cara untuk menyederhanakannya, komentar tidak mungkin memberikan gambaran besar tentang apa yang sedang dilakukan. Dokumentasikan dengan beberapa diagram akan jauh lebih baik. Dan komentar yang merujuk pada dokumentasi eksternal itu harus ditinggalkan. Tentu saja situasi itu harus luar biasa karena kita semua tahu bahwa memelihara dokumentasi eksternal jarang dilakukan, jadi semakin sedikit, semakin baik. Selebihnya, jawaban yang bagus seperti biasa.

— Walfrat

@ Walfrat: niat saya adalah untuk memberikan pedoman umum tentang proses, tidak hanya untuk "50 baris kode SQL", dan bukan sebagai solusi "out-of-the-box" dengan semua pendekatan potensial.

— Doc Brown

Saya tahu, saya hanya ingin menyarankan bahwa jika sesuatu setelah ditinjau berkali-kali tidak dapat disederhanakan cukup (apa pun itu), komentar kemungkinan besar tidak akan membantu tentang apa yang membuat hal ini rumit sehingga dokumentasi eksternal minimal mungkin diperlukan. Dalam kasus khusus kueri basis data, ini bahkan lebih mudah dengan menunjukkan diagram yang menunjukkan bagaimana setiap bagian kueri berkorelasi satu sama lain.

— Walfrat

4

Sulit dibaca tidak buruk - tidak perlu sulit dibaca juga buruk.

Beberapa hal memang sulit. Dalam hal ini, Anda harus benar-benar memahami masalahnya, menulis kodenya, dan berkomentar sebaik mungkin agar pengembang selanjutnya memiliki kesempatan.

Tetapi beberapa hal hanya sulit karena Anda membuatnya sulit. Jika masalah bisa disederhanakan dan dipermudah, sederhanakan. Jika sulit dimengerti tetapi dapat dibagi menjadi beberapa masalah, maka bagi menjadi beberapa masalah untuk menyederhanakannya.

— gnasher729
sumber

Persis. Usahakan sebaik-baiknya untuk membuat kode sendiri-sendiri, lalu gunakan komentar untuk mengisi kekosongan. (diedit: Saya menyadari setelah memposting komentar saya bahwa OP merujuk ke permintaan basis data ORM, bukan SQL.)

— Kyle A

1

ORM untuk membuat laporan? Serius? Pelajari beberapa SQL, bung. Bahasa prosedural mengerikan dalam hal semacam ini.

SQL adalah bahasa yang jauh lebih baik dirancang untuk menangani gabungan dan pemilihan yang rumit. Dan bahkan jika Anda tidak bisa membuat SQL terlihat cantik, ada semua jenis alat visualisasi yang tersedia di mana Anda dapat menarik dan menjatuhkan objek database pada diagram dan SQL akan dihasilkan untuk Anda. Belum lagi Anda akan dapat menyetel dan mengoptimalkan kueri, melihat rencana kueri, mendapatkan platform untuk menyarankan opsi pengindeksan tambahan, dll. Itu hanya cara yang lebih fleksibel.

Saya yakin beberapa orang di sini tidak akan setuju dengan saya, tetapi ORM tidak cocok untuk keperluan pelaporan yang rumit. Jika mungkin saya akan mempertimbangkan untuk menjauh dari itu dan bergerak menuju Structured Query Language.

— John Wu
sumber

2

Jujur saja, fakta bahwa Anda tidak menyukai ORM sama sekali tidak relevan untuk pertanyaan itu.

— Doc Brown

Saya suka ORM. Saya menyatakan bahwa itu bukan alat yang baik ketika kode "bergabung pada beberapa kolom, menerapkan beberapa where dan memilih beberapa kolom berbeda untuk membuat format output yang diperlukan," yang merupakan topik utas ini.

— John Wu

0

Secara umum sulit untuk membaca kode adalah ide yang buruk di mana saja - bahkan jika Anda adalah satu-satunya pemelihara - saya telah beberapa kali kembali ke beberapa kode tahun atau bahkan berminggu-minggu kemudian dan merasa sulit untuk mendapatkan kepalaku.

Jika Anda perlu melakukan banyak hal dalam satu permintaan, cobalah membaginya dalam baris dengan komentar yang tersemat:

query(join(map(condition1, condition2), blah, blah, something(bah, blah, blah)))

Menjadi:

// Why are we doing such an awful single query rather than a sequence of selects?
query( // Description of query
  join( // Why are you doing a join here
    map( // Why a map
      condition1, // What is this
      condition2  // And this
   ), // End Map
   blah, // What, Why?
   blah, // What, Why?
   something( // What does this do?
      bah, // What, Why?
      blah, // What, Why?
      blah // What, Why?
      ) // End Something
   ) // End Join
) // End Query

— Steve Barnes
sumber

Saya tidak jelas tentang contoh Anda. komentar harus menjelaskan mengapa kodenya seperti itu. The apa yang harus diungkapkan oleh pengidentifikasi ...

— Timothy truckle

@TimothyTruckle Saya setuju bahwa pengidentifikasi harus dengan jelas mengidentifikasi siapa mereka tetapi semua sering mereka tidak jelas dalam kode normal - dalam kasus nama field rekaman sering ada kurangnya kejelasan karena kendala historis yang saya temui kasus adalah nama field dibatasi hingga 5 karakter yang semuanya harus huruf ASCII huruf besar & tidak dapat diubah karena persyaratan kompatibilitas, misalnya dengan alat pelaporan favorit MDs.

— Steve Barnes

0

Selain jawaban yang sangat bagus dari @ DocBrown, saya pikir layak untuk mengakui bahwa tidak ada yang menulis kode "baik" sepanjang waktu. Pengodean menghasilkan pertukaran, dan seringkali lebih baik menerima bahwa Anda telah menulis sesuatu yang sedikit kurang bersih daripada yang Anda inginkan dan kembali lagi nanti. Refactoring adalah proses meningkatkan kode dari waktu ke waktu - dan dalam pengalaman saya, itulah yang membuat basis kode yang baik, bukan "lakukan dengan benar pertama kali".

Dan Anda menilai kode pada level aplikasi, bukan pada level metode individu / baris kode. Jadi, jika Anda memiliki metode yang kompleks, tetapi namanya jelas, saya tidak berpikir Anda memiliki kode "buruk" selama metode tersebut kohesif.

Memberi nama adalah senjata terbesar yang Anda miliki dalam membuat kode dapat dipahami - beri nama metode Anda yang memungkinkan orang membaca kode Anda untuk melewati tubuh jika perlu. Beri nama variabel Anda dll. Dengan cara yang berarti pembaca dapat melihat apa yang mereka wakili tanpa harus membaca pernyataan tugas mereka.

Hal berikutnya adalah memastikan metode Anda benar-benar hanya melakukan satu hal - efek samping membuat kode sulit dipahami. Jadi, jika metode Anda mengembalikan data untuk format output, itu tidak seharusnya juga memperbarui status database Anda untuk "dicetak", atau apa pun.

Layering / komponenisasi adalah hal berikutnya yang mungkin Anda lakukan - jika Anda memiliki banyak metode kompleks yang menghasilkan hasil ORM, gabungkan keduanya sehingga pembaca kode Anda dapat berasumsi bahwa mereka semua berperilaku dengan cara yang sama, tidak memiliki efek samping dll.

— Neville Kuyt
sumber