コードファイルが大きすぎるポイント/範囲はどれですか。
私は2〜3k行のファイルをたくさん見つけていますが、それほど大きくなければならないような気がしません。
ソースコードファイルを「大きすぎる」と客観的に呼ぶのに適した基準は何ですか？ソースコードファイルに必要な最大行数などのことはありますか？
理想的なモデルとして、次の基準を使用します（Martin Beckettが提案したのと同様の根拠、つまりコード行ではなく論理構造の観点から考える）。
ルール1
ファイルごとに1つのクラス（C++では、1つのクラス-> 1つのヘッダーと1つの実装ファイル）。
ルール2
7つは、私たちの脳が混乱することなく同時に観察できる項目の数と見なされます。 7を超えると、表示される内容の概要を把握することが困難になります。したがって、各クラスには7〜10を超えるメソッドを含めないでください。 10を超えるメソッドを持つクラスはおそらく複雑すぎるため、分割する必要があります。クラスを分割するたびに、個々のクラスの複雑さを少なくとも2分の1に減らすため、分割は非常に効果的な方法です。
ルール
1つまたは2つの画面に収まらないメソッド本体が大きすぎます（画面/エディターウィンドウは約50行と想定しています）。理想的には、メソッド全体を1つのウィンドウに表示できます。これが当てはまらない場合、非表示になるメソッドの部分を忘れずに、少しだけ上下にスクロールする必要があります。そのため、メソッド本体全体を読むために複数の画面を上下にスクロールする必要がある場合、メソッドが大きすぎて、概要を簡単に失う可能性があります。
繰り返しになりますが、プライベートヘルプメソッドを使用してメソッドを分割すると、メソッドの複雑さを非常に速く減らすことができます（分割するたびに、複雑さは少なくとも半分になります）。あまりにも多くのプライベートヘルプメソッドを導入する場合は、それらを収集するための個別のクラスを作成することを検討できます（パブリックメソッドよりもプライベートメソッドが多い場合、2番目のクラスがメインクラス内に隠れている可能性があります）。
これらの非常に大まかな見積もりをまとめます。
- ソースファイルごとに最大1つのクラス。
- クラスあたり最大10のパブリックメソッド。
- クラスあたり最大10個のプライベートメソッド。
- メソッドあたり最大100行。
そのため、2000行を超えるソースファイルはおそらく大きすぎ、乱雑になり始めています。
これは実際には非常に大まかな見積もりであり、これらの基準には体系的に従いません（特に、適切なリファクタリングを実行するための十分な時間が常にないため）。また、Martin Beckettが示唆したように、クラスがメソッドの大きなコレクションであり、クラスを小さくするためだけに人工的な方法でそれらを分割しても意味がない場合があります。
とにかく、私の経験では、上記のパラメーターのいずれかが順守されていない場合、ファイルが読み取れなくなります（たとえば、6つの画面にまたがる300行のメソッド本体、または5000行のコードを含むソースファイル）。
いいえ-コード行ではありません。ドライバーは論理グループにする必要があります。たとえば、1つの大きなファイルに複数のクラスがあってはいけません。
正当に数百のメソッドがあったクラス（たとえば3Dモデリングでは不可能ではない）がある場合、それを任意のファイルに分割するのははるかに不便です。以前は、メモリが不足していてプロセッサが遅いときにこれを行わなければなりませんでした。そして、関数定義を常に検索するのは面倒でした。
その中のコードが保守できなくなったとき。 ie：探しているメソッド/クラス/関数がコードであるかどうかを確認するだけではわかりません（そして編集/デバッグする必要があります）。あるかどうか、ある場合はどこにあるか。
ただし、IDE /エディターの選択と機能は、この上限の実際の定量化に影響します。 コードの折りたたみ、関数/メソッドのリスト、ルックアップは、この開発シナリオが提示する瞬間にpostponeします。
しかし、それが終わったら、それを分割する時が来ました。
ここに別の見方があります：あなたはファイルサイズを制限する方法について尋ねています。私の意見では、大きなコードファイルを非常に問題にする多くの要因があると思います。コードファイルは非常に大きい場合がありますが、そのコンテンツは適切にクラスター化され、非常にクリーンなコードであるため、サイズによって重大な問題が発生することはありません。 LOCが高いにもかかわらず、非常に読みやすいファイルをたくさん見ました。
LOCメトリックを利用する代わりに、履歴データを使用して、これらの大きなファイルでコードが壊れる頻度を理解することを検討します。通常、その理由は、開発者が同じファイル内の関連する他の場所を確認し、十分に理解せずに「迅速な修正」の考え方で変更を行う忍耐力がないためです。
より大きな危険は、コピーと貼り付けのコードの存在です。コピーと貼り付けのコーディングは、当然LOCの成長を加速します。 LOCをマジックナンバーより低く保つよりも、コピーと貼り付けをなくすことの方が重要だと思います。純粋なコピーと貼り付けに加えて、大きなファイルには2つ目の危険があります。それは機能の重複です。ファイルが大きいほど、同じファイルの別のセクションに既にあるスニペットを再実装する可能性が高くなります。
したがって、バグ修正比率（すべてのコミットに対するバグ修正コミットの比率）が大きいファイルに対して低い限り、状況は許容できます。してみてください git log for itと、エラーに関連するコミットの数を調べます。または、自動的に分析して視覚化できるツールを使用します。 ソフトグラム 。
これを検討してくださいMetaphor。コード長に関しては、次の点を考慮する必要があります。
The Cat in The Hat (50 pp.)
そして
Lord of The Rings (1,178 pp.)
Lord of the Ringsに問題はありません。素晴らしい本です。 The Cat in the Hatもすばらしい本です。どちらも5歳の子供には理解できますが、内容により、どちらか一方だけが適しています。
私の意見では、コードを書くことは、できる限り5歳の人にとって意味のあることです。 Cyclomatic Complexityは、コードを生成するときに開発者が考慮すべき重要な概念です。ライブラリを利用して作成し、機能とコードの再利用性を可能な限り強化します。このようにして、コードは私たちが書いたものよりも多くのボリュームを話すことができます。
ほとんどの人がアセンブリコードを記述していません。しかし、コードのルートはアセンブリです。 10000行を検索する正しく実行すると、アセンブリはPythonの10000行よりも困難になります。
しかし、一部の作業では500〜1000行を書き込む必要があります。コードの目標は、300行のクリーンなコードを書くことです。
開発者として、「ロードオブザリング」を書きたいと思います。バグが発生し、「Cat in the Hat」を書いてほしいと願うまで。コーディングを自我の尺度にしないでください。単純に機能させるだけです。
開発者はコードを文書化したくありません（私は個人的に文書化されたコードが大好きです、私はそれほど利己的ではありません）。ですから、あなただけが理解/読めるコードを書かないでください。 Cat in the Hatコードを記述します。
J.R.R。トルケン（頭の中で）バグのないコードで証明するものは何もないことに注意してください。
比喩のもう一つの理由。
読者を過剰に殺害しないでください。人々のグループで作業していて、全員が同じ大きなファイルを変更する必要がある場合は、おそらくgitマージ地獄にいることになります。
誰もがリベースが大好きです。
->誰も言ったことがない！
TL; DR読みやすさを重視。コードとヘルパーをできるだけ多くの行とファイルに分散します。 1つのファイルに8つまたは9つのクラスを投げないでください。コードが読みにくくなり、保守が難しくなります。条件コードまたはループが大きい場合は、言語でサポートされている場合はそれらをLambdaに変更することを検討してください。ユーティリティ関数は、コードを読みやすくするための優れた手段と考える必要があります。入れ子にしないでください。