Apakah ada jumlah optimal baris kode per fungsi? [Tutup]

18

Fungsi tidak hanya digunakan untuk meminimalkan duplikasi kode - mereka juga digunakan untuk membagi fungsi yang panjang menjadi yang lebih kecil untuk meningkatkan keterbacaan, serta membuat kode berkomentar sendiri. Namun, perolehan ini tidak berbanding terbalik secara langsung dengan jumlah LOC per fungsi atau metode; kalau tidak kita akan memiliki banyak fungsi, yang semuanya hanya berisi satu atau dua baris kode.

Ini membuat saya bertanya-tanya: Apakah ada jumlah optimal LOC per fungsi? Jika demikian, apakah itu, dan apakah itu menyimpang antara bahasa?

functions

— Gablin
sumber

6

Lihat Kode Lengkap Vol 2 oleh Mitch McConnell Bab 7 Bagian 4 untuk waktu yang baik.

— Peter Turner

2

@ Peter - Saya pikir maksud Anda "Steve McConnell"

— JohnFx

Ya, lucu saya menulis itu sambil melihat buku .... Bukankah Mitch McConnell Pres. Kepala staf Bush?

— Peter Turner

3

Jumlahnya hampir pasti bervariasi berdasarkan bahasa: Saya akan terkejut melihat klausa Prolog 6-baris, sementara itu sangat OK dengan metode Delphi 20 baris. Jawaban saya di bawah adalah untuk Smalltalk, yang menggunakan lingkungan untuk mendorong metode pendek.

— Frank Shearar

1

@Peter Turner: Hm ... S1 hingga S15 dan I1 hingga I11. Kedengarannya dia membingungkan variabel sementara dengan register. ^^

— gablin

33

Alih-alih jumlah baris, kriteria yang akan saya gunakan adalah bahwa setiap fungsi harus melakukan hanya satu hal dan melakukannya dengan baik.

— grokus
sumber

Ya, jika kita memiliki unit kerja, saya tidak ingin harus berpindah antara 50 fungsi untuk mendapatkan inti dari apa yang terjadi. Jika Anda menjabarkan fungsi-fungsi Anda secara tepat menggunakan metrik ini, ukurannya seharusnya hampir masuk akal.

— ChaosPandion

2

@ChaosPandion: tetapi unit kerja Anda mungkin dinyatakan sebagai urutan langkah yang lebih mendasar. Jika Anda meninjau fungsi, Anda akan meninjau urutan langkah, bukan kode dari setiap langkah.

— Wizard79

2

@ Lorenzo - Jika demikian halnya, setiap langkah menjadi unit kerja. Fungsi induk menjadi ikhtisar tingkat tinggi dari unit kerja.

— ChaosPandion

1

Ya, ini memang benar. Hm, izinkan saya ulangi pertanyaannya kemudian: Apakah ada jumlah optimal LOC untuk fungsi yang hanya melakukan satu hal, dan melakukannya dengan baik?

— gablin

@ Gablin, sulit untuk dikatakan dan juga LOC tergantung pada bahasa, tetapi jika Anda mematuhi prinsip ini, biasanya Anda berada dalam kisaran yang wajar, katakan 1 ~ 50.

— grokus

21

Aturan jempol lama adalah bahwa suatu fungsi harus sepenuhnya terlihat di layar, tanpa perlu menggulir.

Ide dasarnya adalah bahwa, jika Anda tidak dapat melihat seluruh fungsi pada suatu waktu, fungsi tersebut lebih kompleks, dan Anda harus membaginya dalam potongan-potongan yang lebih mendasar.

Meskipun aturan ini sangat praktis dan berguna, aturan formal adalah bahwa Anda harus menyimpan hanya satu langkah logis dalam suatu fungsi. Suatu fungsi tidak hanya pekerjaan dasar, jika Anda dapat membagi pekerjaan menjadi bagian-bagian yang lebih mendasar, fungsi tersebut harus dipecah.

— Wizard79
sumber

21

Metrik ini menjadi semakin tidak berguna karena ukuran / resolusi monitor rata-rata meningkat.

— Adam Lear

2

Profesor pemrograman kami baru saja mengatakan contoh ini malam sebelumnya :)

— cdnicoll

2

@Anna: baik, monitor saya beresolusi tinggi tetapi juga jumlah toolbar / palet / panel telah meningkat. Dan kemudian, sekarang saya dapat menggunakan font pitch 14 pt! :)

— Wizard79

4

Ukuran terminal 24 x 80 cenderung tidak berubah.

— alternatif

1

omong kosong, inti dari aturan ini adalah "dapatkah Anda melihat semuanya tanpa menggulir". Dengan monitor besar Anda dapat memiliki lebih banyak fungsi tanpa melanggar aturan ini, itu tidak berarti monitor besar hanya diizinkan untuk melihat fungsi kecil (meskipun dengan semua toolbar dan jendela properti yang dimiliki IDE Anda, ini mungkin masih berlaku: - ))

— gbjbaanb

15

Tidak ada.

Layar semakin besar, ukuran font lebih kecil. Aturan praktis tidak berfungsi dengan baik ketika orang memiliki ukuran ibu jari yang berbeda.

Ringkaslah. Jika fungsi Anda melakukan banyak hal, mungkin ide yang bagus untuk memecahnya menjadi lebih kecil.

— Josh K.
sumber

Paling tidak yang bisa Anda lakukan adalah memberi tahu saya mengapa menurut Anda jawaban saya tidak berguna.

— Josh K

7

Saya pikir seseorang tersinggung oleh Anda menggunakan tag h1 .

— ChaosPandion

@Chaos: Itulah jawaban penting.

— Josh K

6

Mungkin saya agak terlalu halus tetapi maksud saya adalah menyiratkan bahwa tidak ada alasan yang sah untuk memilih suara Anda. Siapa pun yang melakukan perbuatan itu memiliki alasan pribadi yang acak untuk melakukannya. Mereka mungkin berpikir Josh adalah nama yang mengerikan.

— ChaosPandion

6

Smalltalk memiliki cara yang agak tidak biasa untuk mengurangi ukuran metode. Saat Anda menulis kode, Anda menulisnya di widget yang disebut Browser. Browser memiliki dua bagian utama, dibagi secara horizontal. Kode Anda berada di bagian bawah.

Secara default, Browser tidak terlalu besar. Anda dapat memasukkan 5 atau 6 baris sebelum Anda harus mulai menggulir. Menggulir, tentu saja, sedikit menjengkelkan.

Jadi di Smalltalk lingkungan "mendorong" Anda untuk menulis metode pendek, paling banyak sekitar 6 baris panjangnya. (Itu biasanya banyak; Smalltalk adalah bahasa yang cukup singkat.)

— Frank Shearar
sumber

2

Jumlah baris kode yang ideal dalam suatu metode adalah variabel. Pada dasarnya, Anda hanya ingin menulis kode yang cukup untuk melakukan apa yang perlu dilakukan dalam konteks definisi fungsi. Saya menganggap ini sebagai semacam Prinsip Tanggung Jawab Tunggal , hanya diterapkan pada metode alih-alih kelas.

Di mana metode memiliki banyak logika, dan sejumlah langkah untuk diselesaikan, maka masuk akal untuk memecah metode menjadi beberapa langkah terpisah. Masing-masing langkah ini akan diekstraksi menjadi metode baru sesuai kebutuhan.

"kalau tidak kita akan memiliki banyak fungsi, yang semuanya hanya berisi satu atau dua baris kode."

Semakin sedikit masing-masing metode, semakin mudah didefinisikan, dan semakin mudah untuk dipahami dan dikelola. Tidak ada yang salah dengan memiliki ratusan metode jika Anda membutuhkannya. Juga, sesuai dengan SRP yang saya sebutkan sebelumnya, menjadi lebih mudah untuk mengekstrak kelas-kelas baru ketika metode-metode tersebut telah dipisahkan menjadi bagian-bagian yang lebih kecil dan lebih mudah dikelola.

— S.Robins
sumber

1

Jawabannya tentu saja 42 .

Penting untuk dicatat: Tidak ada fungsi yang dapat melanggar SRP , atau Anda harus menghadapi inkuisisi spanisch .

Beberapa petunjuk bagaimana mengurangi jumlah baris:

Apakah ada komentar yang menandai bagian individual? Bagian-bagian itu haruslah fungsi.
Apakah ada rantai lain atau pergantian pernyataan di luar pabrik / pembangun? Desain Anda mungkin memerlukan beberapa pola desain yang lebih baik untuk membantu Anda membagi tanggung jawab.
Apakah fungsi Anda mudah diuji? Buat fungsi Anda mudah untuk diuji, mereka akan berantakan.
Apakah kompleks dan tidak ada daratan dalam sigth (1000 monster garis)? Lakukan memo refactoring - yaitu refactor dan jangan menyimpannya dengan harapan mendapatkan edukasi tentang tanggung jawab kode.

— Johannes
sumber

1

Nᴏʙᴏᴅʏ mengharapkan Spanyol ... ah bugger, aku agak terlambat di sini.

— leftaroundabout

0

Berikut ini beberapa petunjuk:

Jika Anda kesulitan menulis komentar yang menjelaskan tujuan dan penggunaan fungsi, itu terlalu lama.
Jika Anda tergoda untuk menulis komentar yang menjelaskan aktivitas bagian kode dalam fungsi, maka fungsinya terlalu panjang.
Jika Anda menempelkan kode dari fungsi lain, maka keduanya terlalu panjang (ekstrak kode itu sebagai fungsi terpisah).
Jika Anda memerlukan konvensi pengkodean untuk memisahkan anggota data kelas dari variabel lokal, maka fungsinya terlalu panjang, dan kelas tersebut memiliki terlalu banyak anggota.
Jika Anda perlu mencatat saat membaca suatu fungsi, itu terlalu lama.

Memiliki 'ton' fungsi, masing-masing panjangnya hanya satu atau dua baris, belum tentu merupakan hal yang buruk. Saya menemukan bahwa fungsi-fungsi kecil itu digunakan kembali lebih dari yang saya harapkan.

— kevin cline
sumber