Berapa panjang ideal metode untuk Anda? [Tutup]

Dalam pemrograman berorientasi objek, tentu saja tidak ada aturan pasti tentang panjang maksimum metode, tetapi saya masih menemukan dua kutipan ini agak saling bertentangan, jadi saya ingin mendengar pendapat Anda.

Dalam Clean Code: A Handbook of Agile Software Craftsmanship , Robert Martin mengatakan:

Aturan fungsi pertama adalah bahwa mereka harus kecil. Aturan fungsi kedua adalah mereka harus lebih kecil dari itu. Fungsinya tidak boleh lebih dari 100 baris. Fungsinya hampir tidak boleh sepanjang 20 baris.

dan dia memberikan contoh dari kode Java yang dilihatnya dari Kent Beck:

Setiap fungsi dalam programnya hanya dua, atau tiga, atau empat baris. Masing-masing jelas secara transparan. Masing-masing bercerita. Dan masing-masing membawa Anda ke yang berikutnya dengan urutan yang menarik. Seharusnya sesingkat apa fungsi Anda!

Ini terdengar hebat, tetapi di sisi lain, dalam Code Complete , Steve McConnell mengatakan sesuatu yang sangat berbeda:

Rutin harus dibiarkan tumbuh secara organik hingga 100-200 baris, bukti selama beberapa dekade mengatakan bahwa rutinitas dengan panjang seperti itu tidak lebih rawan kesalahan daripada rutinitas yang lebih pendek.

Dan dia memberikan referensi untuk penelitian yang mengatakan rutinitas 65 baris atau lebih lama lebih murah untuk dikembangkan.

Jadi, sementara ada perbedaan pendapat tentang masalah ini, adakah praktik terbaik fungsional untuk Anda?

Fungsinya biasanya singkat, antara 5-15 baris adalah "aturan praktis" pribadi saya ketika menulis kode di Java atau C #. Ini adalah ukuran yang baik karena beberapa alasan:

• Ini cocok dengan mudah di layar Anda tanpa menggulir
• Ini tentang ukuran konseptual yang dapat Anda pegang di kepala Anda
• Cukup bermakna untuk membutuhkan fungsi dalam dirinya sendiri (sebagai logika yang berdiri sendiri dan bermakna)
• Fungsi yang lebih kecil dari 5 baris adalah petunjuk bahwa Anda mungkin terlalu banyak memecah kode (yang membuatnya lebih sulit untuk dibaca / dipahami jika Anda perlu menavigasi antar fungsi). Entah itu atau Anda lupa kasus khusus / penanganan kesalahan!

Tapi saya pikir itu tidak membantu untuk menetapkan aturan absolut, karena akan selalu ada pengecualian / alasan yang valid untuk menyimpang dari aturan:

• Fungsi accessor satu garis yang melakukan pemeran tipe jelas dapat diterima dalam beberapa situasi.
• Ada beberapa fungsi yang sangat singkat namun bermanfaat (mis. Swap seperti yang disebutkan oleh pengguna tidak diketahui) yang jelas membutuhkan kurang dari 5 baris. Bukan masalah besar, beberapa fungsi 3 baris tidak membahayakan basis kode Anda.
• Fungsi 100-line yang merupakan pernyataan switch besar tunggal mungkin dapat diterima jika sangat jelas apa yang sedang dilakukan. Kode ini dapat secara konsep sangat sederhana bahkan jika memerlukan banyak baris untuk menggambarkan berbagai kasus. Kadang-kadang disarankan bahwa ini harus di refactored ke dalam kelas yang terpisah dan diimplementasikan menggunakan pewarisan / polimorfisme tetapi IMHO ini mengambil OOP terlalu jauh - saya lebih suka hanya memiliki satu pernyataan peralihan 40 arah yang besar daripada 40 kelas baru yang harus ditangani, selain itu ke pernyataan switch 40-arah untuk membuatnya.
• Fungsi kompleks mungkin memiliki banyak variabel status yang akan menjadi sangat berantakan jika dilewatkan di antara berbagai fungsi sebagai parameter. Dalam hal ini Anda dapat berargumen dengan masuk akal bahwa kode lebih sederhana dan lebih mudah diikuti jika Anda menyimpan semuanya dalam satu fungsi besar (meskipun seperti yang ditunjukkan Mark dengan tepat, ini juga bisa menjadi kandidat untuk berubah menjadi kelas untuk merangkum kedua logika tersebut) dan nyatakan).
• Terkadang fungsi yang lebih kecil atau lebih besar memiliki keunggulan kinerja (mungkin karena alasan inlining atau JIT seperti yang disebutkan Frank). Ini sangat tergantung pada implementasi, tetapi dapat membuat perbedaan - pastikan Anda membuat tolok ukur!

Jadi pada dasarnya, gunakan akal sehat , pertahankan ukuran fungsi kecil di sebagian besar kasus tetapi jangan dogmatis tentang hal itu jika Anda memiliki alasan yang benar-benar bagus untuk membuat fungsi yang luar biasa besar.

Sementara saya setuju dengan komentar orang lain ketika mereka mengatakan tidak ada aturan keras tentang nomor LOC yang tepat, saya bertaruh jika kita melihat kembali proyek yang telah kita lihat di masa lalu dan mengidentifikasi setiap fungsi di atas, katakanlah 150 baris kode, saya ' Saya kira kita akan sampai pada konsensus bahwa 9 dari 10 fungsi tersebut merusak SRP (dan sangat mungkin juga OCP), memiliki terlalu banyak variabel lokal, aliran kontrol terlalu banyak dan umumnya sulit dibaca dan dipelihara.

Jadi, meskipun LOC mungkin bukan indikator langsung kode buruk, tentu indikator tidak langsung yang layak bahwa fungsi tertentu dapat ditulis lebih baik.

Di tim saya, saya jatuh ke posisi memimpin dan untuk alasan apa pun, orang-orang tampaknya mendengarkan saya. Apa yang biasanya saya setujui adalah untuk memberi tahu tim bahwa meskipun tidak ada batasan absolut, fungsi apa pun lebih dari 50 baris kode minimal harus menaikkan bendera merah selama peninjauan kode, sehingga kami melihatnya kembali dan mengevaluasi kembali untuk kompleksitas dan pelanggaran SRP / OCP. Setelah pandangan kedua, kita mungkin membiarkannya sendiri atau mengubahnya, tetapi setidaknya itu membuat orang berpikir tentang hal-hal ini.

Saya melangkah ke proyek yang tidak peduli tentang pedoman pengkodean. Ketika saya melihat kode saya kadang-kadang menemukan kelas dengan lebih dari 6000 baris kode dan kurang dari 10 metode. Ini adalah skenario horor ketika Anda harus memperbaiki bug.

Aturan umum tentang seberapa besar suatu metode harus maksimal kadang-kadang tidak begitu baik. Saya suka aturan oleh Robert C. Martin (Paman Bob): "Metode harus kecil, lebih kecil dari kecil". Saya mencoba menggunakan aturan ini setiap saat. Saya mencoba untuk menjaga metode saya sederhana dan kecil dengan mengklarifikasi bahwa metode saya hanya melakukan satu hal dan tidak lebih.

Ini bukan tentang jumlah baris, ini tentang SRP. Menurut prinsip ini, metode Anda harus melakukan satu dan hanya satu hal.

Jika metode Anda melakukan ini DAN ini DAN ini ATAU itu => itu mungkin melakukan banyak hal. Cobalah untuk melihat metode ini dan menganalisis: "di sini saya mendapatkan data ini, mengurutkannya dan mendapatkan elemen yang saya butuhkan" dan "di sini saya memproses elemen-elemen ini" dan "di sini saya akhirnya menggabungkan mereka untuk mendapatkan hasilnya". "Blok" ini harus di refactored ke metode lain.

Jika Anda hanya mengikuti SRP sebagian besar metode Anda akan kecil dan dengan niat yang jelas.

Tidak benar mengatakan "metode ini> 20 baris jadi itu salah". Hal ini dapat merupakan indikasi bahwa sesuatu mungkin salah dengan metode ini, tidak lebih.

Anda mungkin memiliki 400 saluran beralih dalam suatu metode (sering terjadi di telekomunikasi), dan itu masih tanggung jawab tunggal dan itu benar-benar OK.

Tergantung , serius, benar-benar tidak ada jawaban yang solid untuk pertanyaan ini karena bahasa Anda bekerja dengan masalah, lima sampai lima belas baris yang disebutkan dalam jawaban ini mungkin bekerja untuk C # atau Java, tetapi dalam bahasa lain itu tidak memberikan Anda banyak bekerja dengan. Demikian juga, tergantung pada domain tempat Anda bekerja, Anda mungkin menemukan diri Anda menulis nilai pengaturan kode dalam struktur data yang besar. Dengan beberapa struktur data Anda mungkin memiliki puluhan elemen yang perlu Anda atur, haruskah Anda membagi beberapa hal ke fungsi yang terpisah hanya karena fungsi Anda berjalan lama?

Seperti yang telah dicatat orang lain, aturan praktis yang terbaik adalah bahwa suatu fungsi harus berupa entitas logis tunggal yang menangani satu tugas. Jika Anda mencoba untuk menegakkan aturan kejam yang mengatakan bahwa fungsi tidak boleh lebih dari n baris dan Anda membuat nilai itu terlalu kecil kode Anda akan tumbuh lebih sulit untuk dibaca karena pengembang mencoba dan menggunakan trik mewah untuk menyiasati aturan. Demikian juga, jika Anda mengaturnya terlalu tinggi itu akan menjadi masalah dan dapat menyebabkan kode yang buruk meskipun malas. Taruhan terbaik Anda adalah dengan hanya melakukan tinjauan kode untuk memastikan bahwa fungsi menangani satu tugas dan membiarkannya begitu saja.

Saya pikir satu masalah di sini adalah bahwa panjang fungsi tidak mengatakan apa-apa tentang kerumitannya. LOC (Lines of Code) adalah instrumen yang buruk untuk mengukur apa pun.

Suatu metode seharusnya tidak terlalu rumit, tetapi ada skenario di mana metode yang panjang dapat dengan mudah dipelihara. Perhatikan bahwa contoh berikut tidak mengatakan itu tidak dapat dibagi menjadi metode, hanya saja metode tidak akan mengubah rawatan.

misalnya handler untuk data yang masuk dapat memiliki pernyataan saklar besar dan kemudian kode sederhana per kasus. Saya memiliki kode seperti itu - mengelola data yang masuk dari umpan. 70 (!) Penangan berkode angka. Sekarang, orang akan mengatakan "gunakan konstanta" - ya, kecuali API tidak menyediakannya dan saya ingin tetap dekat dengan "sumber" di sini. Metode? Tentu - sayangnya semuanya berurusan dengan data dari 2 struktur besar yang sama. Tidak ada manfaat dalam memisahkan mereka kecuali mungkin memiliki lebih banyak metode (keterbacaan). Kode ini secara intrinsik tidak rumit - satu sakelar, tergantung pada satu bidang. Kemudian setiap case memiliki blok yang mem-parsing x elemen data dan mempublikasikannya. Tidak ada mimpi buruk pemeliharaan. Ada satu pengulangan "jika kondisi yang menentukan apakah suatu bidang memiliki data (pField = pFields [x], jika pField-> IsSet () {blabla}) - hampir sama untuk setiap bidang ..

Ganti itu dengan rutin yang jauh lebih kecil yang mengandung nested loop dan banyak pernyataan pergantian yang nyata dan metode besar bisa lebih mudah dipelihara daripada yang lebih kecil.

Jadi, maaf, LOC bukanlah pengukuran yang baik untuk memulai. Jika ada, maka poin kompleksitas / keputusan harus digunakan.

Saya hanya akan memberikan penawaran lain.

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

- Harold Abelson

Sangat tidak mungkin bahwa fungsi yang tumbuh hingga 100-200 mengikuti aturan ini

Saya sudah berada di raket gila ini, entah bagaimana, sejak 1970.

Dalam semua waktu itu, dengan dua pengecualian yang akan saya bahas sebentar lagi, saya TIDAK PERNAH melihat "rutin" yang dirancang dengan baik (metode, prosedur, fungsi, subrutin, apa pun) yang PERLU menjadi lebih dari satu halaman yang dicetak ( sekitar 60 baris) panjangnya. Sebagian besar dari mereka agak sedikit pendek, pada urutan 10-20 baris.

Namun, saya telah melihat BANYAK kode "aliran kesadaran", yang ditulis oleh orang-orang yang tampaknya tidak pernah mendengar modularisasi.

Dua pengecualian adalah kasus yang sangat khusus. Yang satu sebenarnya adalah kelas kasus pengecualian, yang saya gabungkan bersama: automata negara-terbatas besar, diimplementasikan sebagai pernyataan peralihan yang jelek, biasanya karena tidak ada cara yang lebih bersih untuk mengimplementasikannya. Hal-hal ini biasanya muncul di peralatan uji otomatis, parsing data log dari perangkat yang diuji.

Yang lainnya adalah foton torpedo rutin dari game STARTRK Matuszek-Reynolds-McGehearty-Cohen, yang ditulis dalam CDC 6600 FORTRAN IV. Itu harus mengurai baris perintah, kemudian mensimulasikan penerbangan masing-masing torpedo, dengan gangguan, memeriksa interaksi antara torpedo dan setiap jenis benda yang bisa mengenai, dan oh dengan cara mensimulasikan rekursi untuk melakukan konektivitas 8 arah pada rantai novae dari torpedo bintang yang di sebelah bintang lainnya.

Jika saya menemukan metode yang panjang, saya bisa bertaruh metode ini tidak diuji unit dengan benar atau sebagian besar waktu tidak memiliki uji unit sama sekali. Jika Anda mulai melakukan TDD, Anda tidak akan pernah membangun metode 100-baris dengan 25 tanggung jawab berbeda dan 5 loop bersarang. Tes mengharuskan Anda terus-menerus memperbaiki kekacauan Anda dan menulis kode bersih paman Bob.

Tidak ada aturan mutlak tentang panjang metode, tetapi aturan berikut ini bermanfaat:

1. Tujuan utama fungsi adalah untuk menemukan nilai balik. Tidak ada alasan lain untuk keberadaannya. Setelah alasan itu terpenuhi, tidak ada kode lain yang harus dimasukkan ke dalamnya. Ini tentu membuat fungsi kecil. Memanggil fungsi lain hanya boleh dilakukan jika itu membuat menemukan nilai kembali lebih mudah.
2. Di sisi lain, antarmuka harus kecil. Ini berarti Anda memiliki banyak kelas, atau Anda memiliki fungsi besar - salah satu dari keduanya akan terjadi setelah Anda mulai memiliki kode yang cukup untuk melakukan sesuatu yang signifikan. Program besar dapat memiliki keduanya.

Apakah penulis mengartikan hal yang sama dengan "fungsi" dan "rutin"? Biasanya ketika saya mengatakan "fungsi" yang saya maksud adalah subrutin / operasi yang mengembalikan nilai dan "prosedur" untuk yang tidak (dan yang panggilannya menjadi pernyataan tunggal). Ini bukan perbedaan umum di seluruh SE di dunia nyata tetapi saya telah melihatnya di teks pengguna.

Either way, tidak ada jawaban yang tepat untuk ini. Preferensi untuk satu atau yang lain (jika ada preferensi sama sekali) adalah sesuatu yang saya harapkan akan sangat berbeda antara bahasa, proyek, dan organisasi; seperti halnya dengan semua konvensi kode.

Satu hal yang saya tambahkan adalah bahwa keseluruhan "operasi panjang tidak lebih rentan kesalahan daripada operasi pendek" pernyataan tidak sepenuhnya benar. Selain fakta bahwa lebih banyak kode sama dengan lebih banyak ruang kesalahan potensial, sangat jelas bahwa memecah kode menjadi segmen akan membuat kesalahan lebih mudah untuk dihindari dan lebih mudah ditemukan. Kalau tidak, tidak akan ada alasan untuk memecah kode menjadi beberapa bagian, simpan pengulangan. Tapi ini mungkin benar hanya jika segmen tersebut didokumentasikan dengan cukup baik sehingga Anda dapat menentukan hasil dari panggilan operasi tanpa membaca atau melacak kode aktual (desain-kontrak berdasarkan spesifikasi daripada ketergantungan nyata antara bidang kode).

Selain itu, jika Anda ingin operasi yang lebih lama bekerja dengan baik, Anda mungkin ingin mengadopsi konvensi kode yang lebih ketat untuk mendukungnya. Melemparkan pernyataan kembali di tengah operasi mungkin baik untuk operasi pendek, tetapi dalam operasi yang lebih lama ini dapat membuat bagian besar kode yang bersyarat tetapi tidak jelas bersyarat pada pembacaan cepat (hanya untuk satu contoh).

Jadi saya akan berpikir bahwa gaya mana yang cenderung menjadi mimpi buruk yang dipenuhi bug sebagian besar akan tergantung pada konvensi apa yang Anda patuhi untuk sisa kode Anda. :)

IMHO, Anda tidak perlu menggunakan scrollbar untuk membaca fungsi Anda. Segera setelah Anda perlu memindahkan bilah gulir, perlu beberapa saat lagi untuk memahami cara kerja fungsinya.

Dengan demikian, itu tergantung pada lingkungan pemrograman yang biasa dari kerja tim Anda (resolusi layar, editor, ukuran font, dll ...). Di 80-an, itu 25 baris dan 80 kolom. Sekarang, pada editor saya, saya menampilkan hampir 50 baris. Jumlah kolom yang saya tampilkan tidak berubah karena saya membagi layar saya menjadi dua untuk menampilkan dua file sekaligus.

Singkatnya, itu tergantung pengaturan rekan kerja Anda.

Saya pikir jawaban TomTom mendekati perasaan saya tentang hal itu.

Semakin banyak saya mendapati diri saya melakukan kompleksitas siklomatik daripada garis.

Saya biasanya bertujuan untuk tidak lebih dari satu struktur kontrol per metode, dengan pengecualian dari berapa banyak loop yang diperlukan untuk menangani array multi-dimensi.

Saya kadang-kadang menemukan diri saya meletakkan seandainya satu-baris dalam kasus beralih karena untuk beberapa alasan ini cenderung menjadi kasus di mana membaginya menghalangi daripada membantu.

Perhatikan bahwa saya tidak menghitung logika penjaga terhadap batas ini.

Dalam OOP semua benda keberatan dan ada fitur-fitur ini:

1. Polimorfisme
2. Abstraksi
3. Warisan

Ketika Anda mematuhi aturan-aturan ini maka metode Anda biasanya kecil tetapi tidak ada aturan untuk aturan kecil atau sangat kecil (misalnya 2-3 baris). Manfaat metode kecil (unit kecil misalnya metode atau fungsi) adalah:

1. lebih mudah dibaca
2. pertahankan lebih baik
3. memperbaiki bug lebih baik
4. berubah lebih baik