Pada titik / rentang apakah file kode terlalu besar?

Saya menemukan banyak file baris 2-3k, dan rasanya tidak terlalu besar.

Apa kriteria yang baik untuk secara objektif menyebut file kode sumber "terlalu besar"?, Adakah yang namanya jumlah maksimum baris yang harus dimiliki file kode sumber?

Sebagai model yang ideal saya menggunakan kriteria berikut (dengan alasan yang sama dengan apa yang disarankan Martin Beckett, yaitu untuk berpikir dalam hal struktur logis dan bukan dalam hal garis kode):

Aturan 1

Satu kelas per file (dalam C ++: satu kelas -> satu header dan satu file implementasi).

Aturan 2

Tujuh dianggap sebagai jumlah benda yang dapat diamati otak kita secara bersamaan tanpa menjadi bingung. Di atas 7 kami merasa sulit untuk menyimpan gambaran tentang apa yang kami lihat. Karena itu: setiap kelas tidak boleh memiliki lebih dari 7-10 metode. Kelas yang memiliki lebih dari 10 metode mungkin terlalu kompleks dan Anda harus mencoba membaginya. Memisahkan adalah metode yang sangat efektif karena setiap kali Anda membagi kelas Anda mengurangi kompleksitas masing-masing kelas individu setidaknya dengan faktor 2.

Aturan 3

Badan metode yang tidak muat dalam satu atau dua layar terlalu besar (saya berasumsi bahwa jendela layar / editor sekitar 50 baris). Idealnya, Anda dapat melihat seluruh metode dalam satu jendela. Jika ini bukan masalahnya, Anda hanya perlu sedikit gulir ke atas dan ke bawah, tanpa melupakan bagian dari metode yang disembunyikan. Jadi, jika Anda harus menggulir lebih dari satu layar ke atas atau ke bawah untuk membaca seluruh badan metode, metode Anda mungkin terlalu besar dan Anda dapat dengan mudah kehilangan gambaran umum.

Sekali lagi, metode pemisahan menggunakan metode bantuan pribadi dapat mengurangi kompleksitas metode dengan sangat cepat (di setiap pemisahan kompleksitas setidaknya berkurang separuh). Jika Anda memperkenalkan terlalu banyak metode bantuan pribadi, Anda dapat mempertimbangkan untuk membuat kelas terpisah untuk mengumpulkannya (jika Anda memiliki lebih banyak metode pribadi daripada yang umum, mungkin kelas kedua bersembunyi di dalam kelas utama Anda).

Menyusun perkiraan kasar ini:

• Paling banyak satu kelas per file sumber.
• Paling banyak 10 metode publik per kelas.
• Paling banyak 10 metode pribadi per kelas.
• Paling banyak 100 baris per metode.

Jadi file sumber yang lebih dari 2000 baris mungkin terlalu besar dan mulai terlalu berantakan.

Ini adalah perkiraan yang sangat kasar dan saya tidak mengikuti kriteria ini secara sistematis (terutama karena tidak selalu ada cukup waktu untuk melakukan refactoring yang tepat). Juga, seperti yang disarankan Martin Beckett, ada situasi di mana kelas merupakan kumpulan metode yang banyak dan tidak masuk akal untuk membaginya dalam beberapa cara buatan hanya untuk membuat kelas lebih kecil.

Bagaimanapun, dalam pengalaman saya, sebuah file mulai tidak dapat dibaca ketika salah satu dari parameter di atas tidak dihormati (mis. Tubuh metode garis 300 yang membentang enam layar, atau file sumber dengan 5.000 baris kode).

Tidak - tidak dalam hal baris kode. Pengemudi harus pengelompokan logis. Misalnya, tidak boleh ada banyak kelas dalam satu file besar

Jika Anda memiliki kelas yang secara sah memiliki beberapa ratus metode (bukan tidak mungkin dalam mengatakan pemodelan 3D) akan jauh lebih mudah untuk memecahnya menjadi file yang sewenang-wenang. Kami dulu harus melakukan ini ketika memori lebih langka dan prosesor lebih lambat - dan itu sangat merepotkan, terus mencari definisi fungsi.

Ketika kode di dalamnya menjadi unmaintainable. yaitu: Anda tidak dapat mengetahui hanya dengan menonton kode jika metode / kelas / fungsi yang Anda cari (dan harus mengedit / debug) ada di sana, atau tidak, dan jika demikian, di mana itu.

Pilihan dan fitur IDE / Editor Anda akan memengaruhi kuantifikasi aktual batas atas ini. Lipat kode , daftar fungsi / metode, dan pencarian akan menunda saat skenario pengembangan ini disajikan.

Tetapi ketika itu terjadi, saatnya untuk membaginya.

Berikut ini adalah pandangan alternatif: Anda bertanya tentang cara membatasi ukuran file. Pendapat saya adalah bahwa ada banyak faktor yang membuat file kode besar sangat bermasalah. Kadang-kadang file kode sangat besar tetapi isinya berkerumun dengan baik dan kode sangat bersih, sehingga ukurannya tidak menyebabkan masalah yang berarti. Saya telah melihat banyak file yang sangat mudah dibaca meskipun LOC tinggi.

Alih-alih memanfaatkan metrik LOC, saya lebih suka berpikir tentang menggunakan data riwayat untuk memahami seberapa sering kode rusak dalam file-file besar. Biasanya alasan untuk itu adalah bahwa pengembang tidak punya waktu untuk bersabar untuk memeriksa tempat-tempat lain yang relevan dalam file yang sama dan melakukan perubahan dengan mentalitas "perbaikan cepat" tanpa cukup pemahaman.

Bahaya yang lebih besar adalah adanya kode copy-paste. Copy-paste coding secara alami juga mempercepat pertumbuhan LOC. Saya pikir menghilangkan copy-paste bahkan lebih penting daripada menjaga LOC di bawah beberapa angka ajaib. Selain copy-paste murni, ada juga bahaya kedua dalam file besar: fungsionalitas yang tumpang tindih. Semakin besar file tersebut, semakin besar kemungkinan Anda akan mengimplementasikan beberapa cuplikan yang sudah ada di bagian lain dari file yang sama.

Jadi, selama rasio perbaikan bug (rasio komitmen perbaikan bug terhadap semua komitmen) rendah untuk file yang lebih besar, situasinya dapat ditoleransi. Silakan coba git logdan lihat berapa banyak komit yang terkait dengan kesalahan. Atau gunakan alat yang dapat secara otomatis menganalisis dan memvisualisasikannya, misalnya Softagram .

Pertimbangkan ini Metaphor. Dalam hal panjang kode, saya pikir kita harus mempertimbangkan hal berikut:

The Cat in The Hat (50 pp.)

dan

Lord of The Rings (1,178 pp.)

Tidak ada yang salah dengan itu Lord of the Rings. Ini buku yang luar biasa. The Cat in the Hatjuga buku yang bagus. Keduanya dapat dipahami oleh anak berusia 5 tahun, tetapi hanya satu yang lebih cocok karena kontennya.

Menurut saya, menulis kode harus masuk akal bagi anak berusia 5 tahun kapan saja kita bisa. Cyclomatic Complexityadalah konsep penting yang harus dipertimbangkan pengembang saat mereka menghasilkan kode. Memanfaatkan dan membuat perpustakaan untuk meningkatkan fungsionalitas dan penggunaan kembali kode sebanyak mungkin. Dengan cara ini kode kami dapat berbicara lebih banyak dari apa yang kami lihat tertulis.

Sebagian besar dari kita tidak menulis kode perakitan . Tapi akar kode kita adalah assembly. Mencari melalui 10.000 baris perakitan lebih sulit daripada 10.000 baris python, jika dilakukan dengan benar.

Tetapi beberapa pekerjaan membutuhkan penulisan 500 hingga 1000 baris. Tujuan kami dengan kode adalah menulis 300 baris kode bersih.

Sebagai pengembang, kami ingin menulis "Lord of The Rings". Sampai kami mendapatkan bug dan berharap kami menulis "Kucing di Topi". Jangan membuat kode sebagai ukuran ego. Jadikan semuanya bekerja dengan cara yang sederhana.

Pengembang tidak ingin mendokumentasikan kode, (Saya suka kode yang didokumentasikan secara pribadi, saya tidak egois). Jadi jangan menulis kode yang hanya bisa Anda pahami / baca. Tulis Cat in the Hatkode

Kita semua tahu Anda adalah JRR Tolken (di kepala Anda). Ingat Anda tidak perlu membuktikan apa pun dengan kode bebas bug.

Alasan lain untuk Metafora.

Jangan berlebihan membaca pembaca menyebarkan kekayaan. Jika Anda bekerja dengan sekelompok orang dan mereka semua harus mengubah file besar yang sama, Anda mungkin akan menempatkan diri Anda dalam gitgabungan neraka.

Semua orang suka rebasing.

-> Kata tidak ada yang pernah!

TL; DR Fokus pada keterbacaan. Sebarkan kode Anda dan bantu lebih dari beberapa baris dan file sebanyak yang Anda bisa. Jangan membuang 8 atau 9 kelas dalam satu file, itu membuat kode sulit dibaca dan sulit untuk dipelihara. Jika Anda memiliki kode kondisi atau loop besar, pertimbangkan untuk mengubahnya ke Lambdas jika bahasa mendukungnya. Fungsi utilitas harus dianggap sebagai cara yang bagus untuk meningkatkan keterbacaan kode. Hindari bersarang berat.