Kapan suatu fungsi terlalu panjang? [Tutup]


130

35 baris, 55 baris, 100 baris, 300 baris? Kapan Anda harus mulai memecahnya? Saya bertanya karena saya memiliki fungsi dengan 60 baris (termasuk komentar) dan sedang berpikir untuk memecahnya.

long_function(){ ... }

ke:

small_function_1(){...}
small_function_2(){...}
small_function_3(){...}

Fungsi tidak akan digunakan di luar fungsi long_, membuat fungsi yang lebih kecil berarti lebih banyak panggilan fungsi, dll.

Kapan Anda akan memecah suatu fungsi menjadi yang lebih kecil? Mengapa?

  1. Metode seharusnya hanya melakukan satu hal logis (pikirkan fungsionalitas)
  2. Anda harus dapat menjelaskan metode ini dalam satu kalimat
  3. Itu harus sesuai dengan ketinggian layar Anda
  4. Hindari overhead yang tidak perlu (komentar yang menunjukkan yang sudah jelas ...)
  5. Pengujian unit lebih mudah untuk fungsi logis kecil
  6. Periksa apakah bagian dari fungsi dapat digunakan kembali oleh kelas atau metode lain
  7. Hindari kopling antar kelas yang berlebihan
  8. Hindari struktur kontrol yang sangat bersarang

Terima kasih semuanya atas jawabannya , edit daftar dan pilih jawaban yang benar saya akan memilih yang itu;)

Saya refactoring sekarang dengan ide-ide itu dalam pikiran :)


Ada salah ketik dalam pertanyaan Anda, saya pikir Anda maksudkan "Kapan suatu fungsi terlalu panjang?".
Tom

1
Anda salah menuliskan pertanyaan dengan mengajukannya dalam hal baris kode. Faktor penentu tidak diukur dalam baris kode.
dkretz

pertanyaan ini dapat menjadi rumit tergantung pada kode dan bahasa. mungkin Anda bisa mempostingnya.
Ray Tayek

Jika dipatuhi prinsip tanggung jawab tunggal - lakukan saja. Saya biasanya merasa perlu membuat header atau untuk setiap 20 baris kode, yang menandai saya untuk abstrak dan menamai fragmen ini dengan fungsi dengan nama yang bermakna alih-alih membuat header bab.
Yevgeniy Afanasyev

Jawaban:


75

Tidak ada aturan keras dan cepat untuk itu. Secara umum saya suka metode saya hanya "melakukan satu hal". Jadi jika itu mengambil data, lalu melakukan sesuatu dengan data itu, kemudian menulisnya ke disk maka saya akan membagi ambil dan menulis menjadi metode yang terpisah sehingga metode "utama" saya hanya berisi "melakukan sesuatu".

"Melakukan sesuatu" itu masih bisa menjadi beberapa baris, jadi saya tidak yakin beberapa baris adalah metrik yang tepat untuk digunakan :)

Sunting: Ini adalah satu baris kode yang saya kirimkan di tempat kerja minggu lalu (untuk membuktikan suatu hal .. itu bukan sesuatu yang saya biasakan :)) - Saya pasti tidak ingin 50-60 bocah nakal ini dalam metode saya : D

return level4 != null ? GetResources().Where(r => (r.Level2 == (int)level2) && (r.Level3 == (int)level3) && (r.Level4 == (int)level4)).ToList() : level3 != null ? GetResources().Where(r => (r.Level2 == (int)level2) && (r.Level3 == (int)level3)).ToList() : level2 != null ? GetResources().Where(r => (r.Level2 == (int)level2)).ToList() : GetAllResourceList();

1
LOL Yah saya bisa menghapus semua spasi putih dalam metode saya dan itu hanya akan menjadi satu baris yang sangat panjang dan bukan fungsi yang panjang. Melakukan satu hal, itu mungkin jawabannya, terima kasih

@Movaxes Potongan kode yang saya posting adalah pernyataan tunggal, tidak hanya banyak baris pada satu baris .. tidak ada semi-titik dua di sana :) Saya bisa memperluas GetResources () setiap kali membuatnya lebih jahat: P
Steven Robbins

Ya itu masuk akal. Mengapa tidak mengambil seluruh file sumber Anda dan meletakkannya dalam satu baris. Maksudku maka Anda benar-benar bisa menjadi Web 2.0 "Ninja" :)
BobbyShaftoe

Saya ingat di majalah-majalah lama (saya berbicara BBC Micro lama) mereka dulu memiliki "program 10 baris" yang hanya memiliki beberapa pernyataan pada setiap baris, hingga panjang maksimal BBC bisa menangani .. mereka selalu sakit yang tepat untuk mengetik: D
Steven Robbins

6
Saya suka konsep fungsi melakukan hanya satu hal, .... tetapi. Jika Anda memiliki fungsi yang melakukan 10 hal, dan Anda memindahkan 9 hal itu ke fungsi yang terpisah, yang masih dipanggil oleh fungsi yang tersisa bukankah fungsi yang tersisa masih pada dasarnya melakukan 10 hal! Saya pikir memecah fungsi seperti ini membuatnya lebih mudah untuk diuji.
mtnpaul

214

Berikut adalah daftar tanda merah (tanpa urutan tertentu) yang dapat menunjukkan bahwa suatu fungsi terlalu panjang:

  1. Struktur kontrol yang bersarang : misalnya untuk loop 3 level atau bahkan hanya 2 level dengan pernyataan if bersarang yang memiliki kondisi kompleks.

  2. Terlalu banyak parameter yang menentukan negara : Dengan parameter yang menentukan negara , maksud saya parameter fungsi yang menjamin jalur eksekusi tertentu melalui fungsi. Dapatkan terlalu banyak dari jenis parameter ini dan Anda memiliki ledakan kombinatorial dari jalur eksekusi (ini biasanya terjadi bersamaan dengan # 1).

  3. Logika yang diduplikasi dalam metode lain : penggunaan kembali kode yang buruk adalah kontributor besar untuk kode prosedural monolitik. Banyak duplikasi logika seperti itu bisa sangat halus, tetapi begitu difaktorkan ulang, hasil akhirnya bisa menjadi desain yang jauh lebih elegan.

  4. Kopling antar kelas yang berlebihan : kurangnya enkapsulasi yang tepat menghasilkan fungsi yang berkaitan dengan karakteristik intim dari kelas lain, sehingga memperpanjang mereka.

  5. Overhead yang tidak perlu : Komentar yang menunjukkan kelas yang jelas, sangat bersarang, getter dan setter yang berlebihan untuk variabel kelas bersarang pribadi, dan nama fungsi / variabel yang panjang dapat membuat kebisingan sintaksis dalam fungsi terkait yang pada akhirnya akan menambah panjangnya.

  6. Tampilan tingkat pengembang besar Anda tidak cukup besar untuk menampilkannya : Sebenarnya, tampilan hari ini cukup besar sehingga fungsi yang mendekati ketinggiannya mungkin terlalu lama. Tetapi, jika lebih besar , ini adalah senjata merokok bahwa ada sesuatu yang salah.

  7. Anda tidak dapat segera menentukan tujuan fungsi : Selain itu, setelah Anda benar - benar menentukan tujuannya, jika Anda tidak dapat meringkas tujuan ini dalam satu kalimat atau kebetulan memiliki sakit kepala yang luar biasa, ini harus menjadi petunjuk.

Kesimpulannya, fungsi monolitik dapat memiliki konsekuensi yang luas dan seringkali merupakan gejala dari defisiensi desain utama. Setiap kali saya menemukan kode yang merupakan kegembiraan mutlak untuk dibaca, keanggunannya segera terlihat. Dan coba tebak: fungsinya seringkali sangat pendek.


1
Pos yang bagus! Sangat deterministik
Chuck Conway

2
@PedroMorteRolo Persis. API standar tidak selalu merupakan model keanggunan. Selain itu, sebagian besar Java API dikembangkan dengan pengetahuan yang mendalam tentang Java Compiler dan JVM, karenanya Anda memiliki pertimbangan kinerja yang dapat menjelaskannya. Saya mengakui bahwa bagian penting dari kode yang tidak dapat membuang satu milidetik mungkin harus melanggar beberapa aturan ini, tetapi itu harus selalu dianggap sebagai kasus khusus. Menghabiskan waktu pengembangan ekstra di muka adalah investasi awal yang dapat menghindari utang teknologi di masa depan (berpotensi melumpuhkan).
Ryan Delucchi

2
Ngomong-ngomong .. Saya berpendapat bahwa metode lama-buruk-heuristik juga berlaku untuk kelas. IMHO, kelas panjang buruk, karena mereka cenderung melanggar prinsip responsabilitas tunggal. Akan menyenangkan untuk memiliki kompiler yang mengeluarkan peringatan untuk kelas panjang dan metode ....
Pedro Rolo

3
@PedroMorteRolo Saya pasti setuju dengan yang ini. Lebih jauh, kelas-kelas besar cenderung memiliki status yang bisa berubah-ubah: yang mengarah pada kode yang sangat sulit dipertahankan.
Ryan Delucchi

1
Jawaban Terbaik. Petunjuk bagus lainnya adalah: seperti apa komentar dalam kode? Jumlah kali aku sengaja menemukan kode seseorang dengan baris seperti: // fetch Foo's credentials where Bar is "uncomplete". Itu hampir pasti nama fungsi di sana dan harus dipisahkan. Mungkin ingin di refactored menjadi sesuatu seperti: Foo.fetchCredentialWhereBarUncomplete()
Jay Edwards

28

Saya pikir ada peringatan besar untuk mantra "do only one thing" pada halaman ini. Terkadang melakukan satu hal menyulap banyak variabel. Jangan memecah fungsi panjang menjadi banyak fungsi yang lebih kecil jika fungsi yang lebih kecil akhirnya memiliki daftar parameter yang panjang. Melakukan hal itu hanya mengubah satu fungsi menjadi satu set fungsi yang sangat digabungkan tanpa nilai individu nyata.


18

Suatu fungsi seharusnya hanya melakukan satu hal. Jika Anda melakukan banyak hal kecil dalam suatu fungsi, buatlah setiap hal kecil berfungsi dan panggil fungsi-fungsi itu dari fungsi lama.

Apa yang benar - benar tidak ingin Anda lakukan adalah menyalin dan menempel setiap 10 baris fungsi panjang Anda ke fungsi pendek (seperti contoh Anda sarankan).


Ya membuat banyak fungsi kecil dengan pola salin & tempel bukan ide bagus, saya setuju fungsi harus selalu mencoba untuk hanya melakukan satu hal

"lakukan satu hal" mungkin atau mungkin tidak benar, tergantung pada rinciannya. Jika suatu fungsi mengalikan sebuah matriks, itu tidak masalah. Jika suatu fungsi membangun mobil virtual - itu adalah "satu hal" tetapi itu juga merupakan hal yang sangat besar. Berbagai fungsi dapat digunakan untuk membuat mobil, komponen demi komponen.
void.pointer

16

Saya setuju bahwa suatu fungsi seharusnya hanya melakukan satu hal, tetapi pada tingkat apa satu hal itu.

Jika 60 baris Anda mencapai satu hal (dari perspektif program Anda) dan potongan-potongan yang membentuk 60 baris itu tidak akan digunakan oleh hal lain, 60 baris itu baik-baik saja.

Tidak ada manfaat nyata untuk memecahnya, kecuali Anda dapat memecahnya menjadi potongan-potongan beton yang berdiri sendiri. Metrik yang digunakan adalah fungsionalitas dan bukan baris kode.

Saya telah bekerja di banyak program di mana penulis mengambil satu-satunya hal ke tingkat yang ekstrem dan yang akhirnya dilakukan adalah membuatnya tampak seperti seseorang membawa granat ke suatu fungsi / metode dan meledakkannya menjadi belasan potongan yang tidak terhubung yang sulit diikuti.

Saat mengeluarkan bagian-bagian dari fungsi itu, Anda juga perlu mempertimbangkan apakah Anda akan menambahkan overhead yang tidak perlu dan menghindari melewatkan sejumlah besar data.

Saya percaya kuncinya adalah mencari reuseability dalam fungsi yang panjang dan menarik bagian-bagian itu keluar. Yang tersisa adalah fungsi, apakah panjangnya 10, 20, atau 60 baris.


2
+1 "Metrik yang digunakan adalah fungsionalitas dan bukan baris kode"
Cody Piersall

Metrik penting lainnya adalah jumlah tingkat blok bersarang. Tetap seminimal mungkin. Memecah suatu fungsi menjadi bagian-bagian kecil sering membantu. Hal-hal lain juga dapat membantu, seperti pengembalian berganda.
user2367418

10

60 baris besar tetapi tidak terlalu panjang untuk suatu fungsi. Jika itu pas di satu layar di editor Anda bisa melihatnya sekaligus. Itu benar-benar tergantung pada apa fungsi yang dilakukan.

Mengapa saya dapat memecah suatu fungsi:

  • Ini terlalu panjang
  • Itu membuat kode lebih mudah dikelola dengan memecahnya dan menggunakan nama yang bermakna untuk fungsi baru
  • Fungsi ini tidak kohesif
  • Bagian dari fungsi berguna dalam dirinya sendiri.
  • Ketika sulit untuk datang dengan nama yang bermakna untuk fungsi (Mungkin melakukan terlalu banyak)

3
Poin bagus, saya setuju, juga jika Anda harus memberi nama fungsi DoThisAndThisAndAlsoThis mungkin terlalu banyak. terima kasih :)

2
Anda hanya tidak cocok dengan pasangan ini. 60 baris akan selalu terlalu banyak. Saya akan mengatakan bahwa jika Anda mendekati 10 baris Anda mungkin mendekati batas.
willcodejavaforfood

Tetapi fungsi lain masih memanggil fungsi-fungsi ini dan pada dasarnya DoThisAndThisAndAlsoThisfungsi yang sama tetapi dengan banyak abstraksi yang masih harus Anda sebutkan entah bagaimana
Timo Huovinen

6

Heuristik pribadi saya adalah terlalu lama jika saya tidak dapat melihat semuanya tanpa menggulir.


4
... selagi mengatur ukuran font menjadi 5?
EricSchaefer

5

Ukuran kira-kira ukuran layar Anda (jadi dapatkan layar lebar pivot besar dan putar) ... :-)

Di samping lelucon, satu hal logis per fungsi.

Dan hal positifnya adalah pengujian unit jauh lebih mudah dilakukan dengan fungsi logis kecil yang melakukan 1 hal. Fungsi besar yang melakukan banyak hal lebih sulit untuk diverifikasi!

/ Johan


Titik yang baik tentang unit testing :)

5

Rule of thumb: Jika suatu fungsi berisi blok kode yang melakukan sesuatu, yang agak terlepas dari sisa kode, letakkan di fungsi yang terpisah. Contoh:

function build_address_list_for_zip($zip) {

    $query = "SELECT * FROM ADDRESS WHERE zip = $zip";
    $results = perform_query($query);
    $addresses = array();
    while ($address = fetch_query_result($results)) {
        $addresses[] = $address;
    }

    // now create a nice looking list of
    // addresses for the user
    return $html_content;
}

jauh lebih baik:

function fetch_addresses_for_zip($zip) {
    $query = "SELECT * FROM ADDRESS WHERE zip = $zip";
    $results = perform_query($query);
    $addresses = array();
    while ($address = fetch_query_result($results)) {
        $addresses[] = $address;
    }
    return $addresses;
}

function build_address_list_for_zip($zip) {

    $addresses = fetch_addresses_for_zip($zip);

    // now create a nice looking list of
    // addresses for the user
    return $html_content;
}

Pendekatan ini memiliki dua keunggulan:

  1. Setiap kali Anda perlu mengambil alamat untuk kode pos tertentu, Anda dapat menggunakan fungsi yang tersedia.

  2. Ketika Anda perlu membaca fungsi build_address_list_for_zip()lagi Anda tahu apa yang akan dilakukan oleh blok kode pertama (itu mengambil alamat untuk kode pos tertentu, setidaknya itulah yang dapat Anda peroleh dari nama fungsi). Jika Anda telah meninggalkan kode kueri sebaris, Anda harus terlebih dahulu menganalisis kode itu.

[Di sisi lain (saya akan menolak saya katakan ini, bahkan di bawah siksaan): Jika Anda membaca banyak tentang optimasi PHP, Anda bisa mendapatkan ide untuk menjaga jumlah fungsi sekecil mungkin, karena pemanggilan fungsi sangat, sangat mahal di PHP. Saya tidak tahu tentang itu karena saya tidak pernah melakukan tolok ukur. Jika demikian, Anda mungkin lebih baik tidak mengikuti jawaban atas pertanyaan Anda jika aplikasi Anda sangat "sensitif kinerja" ;-)]


terima kasih contoh yang bagus :) Saya akan google untuk fungsi benchmark di php

5

Mengintip siklomatik McCabe, di mana ia memecah kodenya menjadi grafik di mana, "Setiap node dalam grafik sesuai dengan blok kode dalam program di mana alirannya berurutan dan busur sesuai dengan cabang yang diambil dalam program. "

Sekarang bayangkan kode Anda tidak memiliki fungsi / metode; itu hanya satu bentangan besar kode dalam bentuk grafik.

Anda ingin memecah gepeng ini menjadi metode. Pertimbangkan itu, ketika Anda melakukannya, akan ada sejumlah blok dalam setiap metode. Hanya satu blok dari masing-masing metode yang akan terlihat oleh semua metode lain: blok pertama (kami menganggap Anda akan dapat melompat ke metode hanya pada satu titik: blok pertama). Semua blok lain dalam setiap metode akan menjadi informasi yang disembunyikan di dalam metode itu, tetapi setiap blok dalam suatu metode berpotensi melompat ke blok lain dalam metode itu.

Untuk menentukan ukuran metode Anda dalam hal jumlah blok per metode, satu pertanyaan yang mungkin Anda tanyakan pada diri sendiri adalah: berapa banyak metode yang harus saya miliki untuk meminimalkan jumlah potensi ketergantungan (MPE) maksimum di antara semua blok?

Jawaban itu diberikan oleh persamaan. Jika r adalah jumlah metode yang meminimalkan MPE sistem, dan n adalah jumlah blok dalam sistem, maka persamaannya adalah: r = sqrt (n)

Dan dapat ditunjukkan bahwa ini memberikan jumlah blok per metode menjadi, juga, sqrt (n).


4

Ingatlah bahwa Anda dapat berakhir dengan memfaktorkan ulang hanya untuk kepentingan ulang anjak piutang, berpotensi membuat kode lebih tidak dapat dibaca daripada sebelumnya.

Mantan kolega saya memiliki aturan aneh bahwa suatu fungsi / metode hanya boleh berisi 4 baris kode! Dia mencoba untuk berpegang teguh pada hal ini sehingga nama metodenya sering menjadi berulang & tidak berarti ditambah panggilan menjadi sangat bersarang & membingungkan.

Jadi mantra saya sendiri telah menjadi: jika Anda tidak bisa memikirkan nama fungsi / metode yang layak untuk potongan kode yang Anda re-factoring, jangan repot-repot.


2

Alasan utama saya biasanya memecah fungsi adalah karena potongan-potongan itu juga bahan dalam fungsi terdekat saya sedang menulis, sehingga bagian-bagian umum bisa diperhitungkan. Juga, jika menggunakan banyak bidang atau properti dari beberapa kelas lain, ada kemungkinan besar potongan yang relevan dapat dihapus secara grosir dan jika mungkin dipindahkan ke kelas lain.

Jika Anda memiliki blok kode dengan komentar di bagian atas, pertimbangkan menariknya ke dalam fungsi, dengan fungsi dan nama argumen yang menggambarkan tujuannya, dan menyimpan komentar untuk alasan kode.

Apakah Anda yakin tidak ada bagian di sana yang akan berguna di tempat lain? Fungsi macam apa itu?


Fungsi membuat file cache dari templat, berdasarkan url, seperti post_2009_01_01.html dari url / post /

2

Menurut pendapat saya jawabannya adalah: ketika itu melakukan terlalu banyak hal. Fungsi Anda harus melakukan hanya tindakan yang Anda harapkan dari nama fungsi itu sendiri. Hal lain yang perlu dipertimbangkan adalah jika Anda ingin menggunakan kembali beberapa bagian dari fungsi Anda di tempat lain; dalam hal ini bisa bermanfaat untuk membaginya.


2

Saya biasanya memecah fungsi oleh kebutuhan untuk menempatkan komentar yang menggambarkan blok kode berikutnya. Apa yang sebelumnya masuk ke komentar sekarang masuk ke nama fungsi baru. Ini bukan aturan yang sulit, tetapi (bagi saya) aturan praktis yang bagus. Saya suka berbicara kode untuk dirinya sendiri lebih baik daripada yang membutuhkan komentar (karena saya telah belajar bahwa komentar biasanya berbohong)


Saya suka mengomentari kode saya, kebanyakan bukan untuk saya tetapi untuk orang lain, yang menghilangkan banyak pertanyaan tentang di mana $ variabel didefinisikan, tetapi saya juga suka kode untuk menjelaskan sendiri. Apakah komentar berbohong?

ya, karena lebih sering daripada tidak dipelihara. Pada saat penulisan mereka mungkin benar, tetapi sekali perbaikan bug atau fitur baru diperkenalkan, tidak ada yang memaksa komentar untuk diubah sesuai dengan situasi baru. Nama-nama metode cenderung berbohong jauh lebih jarang daripada komentar IMHO
Olaf Kock

Saya baru saja menemukan jawaban ini: stackoverflow.com/questions/406760/… menyatakan bahwa "Sebagian besar komentar dalam kode sebenarnya merupakan bentuk yang merusak dari duplikasi kode". Juga - Garis panjang komentar di sana.
Olaf Kock

1

Ini sebagian adalah masalah selera, tetapi bagaimana saya menentukan ini adalah saya mencoba untuk menjaga fungsi saya kira-kira hanya selama akan muat di layar saya pada satu waktu (maksimal). Alasannya adalah bahwa lebih mudah untuk memahami apa yang terjadi jika Anda dapat melihat semuanya sekaligus.

Ketika saya kode, itu campuran menulis fungsi panjang, kemudian refactoring untuk menarik bit yang dapat digunakan kembali oleh fungsi lain - dan - menulis fungsi kecil yang melakukan tugas-tugas terpisah saat saya pergi.

Saya tidak tahu bahwa ada jawaban benar atau salah untuk ini (misalnya, Anda dapat menetapkan 67 baris sebagai maks Anda, tetapi mungkin ada saatnya masuk akal untuk menambahkan beberapa lagi).


Yah saya juga suka melihat fungsi lengkap saya di layar :) kadang-kadang itu berarti font Monospace 9 dan resolusi besar di latar belakang hitam, saya setuju lebih mudah untuk memahaminya seperti itu.

1

Ada beberapa penelitian menyeluruh yang dilakukan pada topik ini, jika Anda ingin bug paling sedikit, kode Anda tidak boleh terlalu lama. Tapi itu juga tidak boleh terlalu pendek.

Saya tidak setuju bahwa suatu metode harus sesuai dengan tampilan Anda dalam satu, tetapi jika Anda menggulir ke bawah lebih dari satu halaman maka metode itu terlalu panjang.

Lihat Ukuran Kelas Optimal untuk Perangkat Lunak Berorientasi Objek untuk diskusi lebih lanjut.


terima kasih untuk tautannya, baca :)

1

Saya telah menulis 500 fungsi baris sebelumnya, namun ini hanya pernyataan peralihan besar untuk mendekode dan merespons pesan. Ketika kode untuk satu pesan menjadi lebih kompleks daripada satu jika-maka-lain, saya mengekstraknya.

Intinya, meskipun fungsinya 500 garis, wilayah yang dipelihara secara independen rata-rata 5 garis.


1

Saya biasanya menggunakan pendekatan tes didorong untuk menulis kode. Dalam pendekatan ini ukuran fungsi sering terkait dengan rincian pengujian Anda.

Jika tes Anda cukup fokus maka akan membuat Anda menulis fungsi fokus kecil untuk lulus ujian.

Ini juga bekerja ke arah lain. Fungsinya harus cukup kecil untuk diuji secara efektif. Jadi ketika bekerja dengan kode lama saya sering menemukan bahwa saya memecah fungsi yang lebih besar untuk menguji bagian-bagian yang berbeda.

Saya biasanya bertanya pada diri sendiri "apa tanggung jawab fungsi ini" dan jika saya tidak dapat menyatakan tanggung jawab dalam kalimat singkat yang jelas, dan kemudian menerjemahkannya menjadi tes fokus kecil, saya bertanya-tanya apakah fungsinya terlalu besar.


1

Jika memiliki lebih dari tiga cabang, umumnya ini berarti bahwa suatu fungsi atau metode harus dipecah, untuk merangkum logika percabangan dalam metode yang berbeda.

Masing-masing untuk loop, jika pernyataan, dll maka tidak dilihat sebagai cabang dalam metode panggilan.

Cobertura untuk kode Java (dan saya yakin ada alat lain untuk bahasa lain) menghitung jumlah jika, dll dalam suatu fungsi untuk setiap fungsi dan menjumlahkannya untuk "kompleksitas siklomatik rata-rata".

Jika fungsi / metode hanya memiliki tiga cabang, itu akan mendapatkan tiga pada metrik itu, yang sangat bagus.

Terkadang sulit untuk mengikuti pedoman ini, yaitu untuk memvalidasi input pengguna. Namun demikian menempatkan cabang dalam metode yang berbeda tidak hanya membantu pengembangan dan pemeliharaan tetapi pengujian juga, karena input ke metode yang melakukan percabangan dapat dianalisis dengan mudah untuk melihat input apa yang perlu ditambahkan ke kasus uji untuk menutupi cabang yang tidak tertutup.

Jika semua cabang berada di dalam metode tunggal, input harus dilacak sejak awal metode, yang menghambat testabilitas.


0

Saya kira Anda akan menemukan banyak jawaban untuk ini.

Saya mungkin akan memecahnya berdasarkan tugas logis yang sedang dilakukan dalam fungsi. Jika Anda melihat bahwa cerita pendek Anda berubah menjadi sebuah novel, saya sarankan mencari dan mengekstrak langkah-langkah yang berbeda.

Misalnya, jika Anda memiliki fungsi yang menangani beberapa jenis input string dan mengembalikan hasil string, Anda mungkin memecah fungsi berdasarkan logika untuk membagi string Anda menjadi beberapa bagian, logika untuk menambahkan karakter tambahan dan logika untuk memasukkannya semua kembali bersama lagi sebagai hasil yang diformat.

Singkatnya, apa pun yang membuat kode Anda bersih dan mudah dibaca (apakah itu hanya dengan memastikan fungsi Anda memiliki komentar yang baik atau memecahnya) adalah pendekatan terbaik.


0

dengan asumsi bahwa Anda melakukan satu hal, panjangnya akan tergantung pada:

  • apa yang kamu lakukan
  • bahasa apa yang Anda gunakan
  • berapa banyak level abstraksi yang perlu Anda tangani dalam kode

60 baris mungkin terlalu panjang atau mungkin tepat. Saya curiga mungkin terlalu lama.


Aku melakukan beberapa caching di PHP, ya mungkin 60 baris terlalu banyak, refactoring ...

0

Satu hal (dan hal itu harus jelas dari nama fungsi), tetapi tidak lebih dari satu layar penuh kode, terlepas dari itu. Dan jangan ragu untuk menambah ukuran font Anda. Dan jika ragu, ubah menjadi dua fungsi atau lebih.


0

Memperluas semangat tweet dari Paman Bob beberapa waktu lalu, Anda tahu sebuah fungsi menjadi terlalu lama ketika Anda merasa perlu untuk menempatkan garis kosong di antara dua baris kode. Gagasannya adalah bahwa jika Anda memerlukan baris kosong untuk memisahkan kode, tanggung jawab dan ruang lingkupnya terpisah pada saat itu.


0

Gagasan saya adalah jika saya harus bertanya pada diri sendiri apakah terlalu lama, mungkin terlalu lama. Ini membantu membuat fungsi yang lebih kecil, di bidang ini, karena bisa membantu nanti dalam siklus hidup aplikasi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.