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?
sumber
switchpernyataan dengan 100casekondisi yang lebih dipertahankan dari 10 tingkat dariifpernyataan bersarang dalam satu sama lain.Jawaban:
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:
Tapi saya pikir itu tidak membantu untuk menetapkan aturan absolut, karena akan selalu ada pengecualian / alasan yang valid untuk menyimpang dari aturan:
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.
sumber
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.
sumber
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.
sumber
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.
sumber
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.
sumber
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.
sumber
Saya hanya akan memberikan penawaran lain.
Sangat tidak mungkin bahwa fungsi yang tumbuh hingga 100-200 mengikuti aturan ini
sumber
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.
sumber
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.
sumber
Tidak ada aturan mutlak tentang panjang metode, tetapi aturan berikut ini bermanfaat:
sumber
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. :)
sumber
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.
sumber
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.
sumber
Dalam OOP semua benda keberatan dan ada fitur-fitur ini:
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:
sumber