コードファイルはどのポイント/範囲で大きすぎますか？

たくさんの2-3k行のファイルを見つけていますが、それほど大きくはないようです。

ソースコードファイルを客観的に「大きすぎる」と呼ぶのに適した基準は何ですか？

理想的なモデルとして、私は次の基準を使用します（Martin Beckettが提案したものと同様の理論的根拠、つまり、コード行ではなく論理構造の観点から考える）。

ルール1

ファイルごとに1つのクラス（C ++の場合：1つのクラス-> 1つのヘッダーと1つの実装ファイル）。

ルール2

7つは、混乱することなく脳が同時に観察できるアイテムの数と見なされます。7を超えると、表示されているものの概要を把握することが困難になります。したがって、各クラスには7〜10個を超えるメソッドを含めることはできません。10個を超えるメソッドを持つクラスは、おそらく複雑すぎるため、分割する必要があります。クラスを分割するたびに、個々のクラスの複雑さを少なくとも2分の1に減らすため、分割は非常に効果的な方法です。

ルール3

1つまたは2つの画面に収まらないメソッド本体が大きすぎます（画面/エディターウィンドウは約50行であると想定しています）。理想的には、1つのウィンドウにメソッド全体を表示できます。そうでない場合は、非表示になるメソッドの部分を忘れずに、少し上下にスクロールするだけで済みます。したがって、メソッド本体全体を読むために複数の画面を上下にスクロールする必要がある場合、メソッドが大きすぎる可能性があり、概要を簡単に失う可能性があります。

繰り返しになりますが、プライベートヘルプメソッドを使用してメソッドを分割すると、メソッドの複雑さを非常に速く減らすことができます（分割するたびに、複雑さが少なくとも半分になります）。あまりにも多くのプライベートヘルプメソッドを導入する場合は、それらを収集するために別のクラスを作成することを検討できます（パブリックメソッドよりもプライベートメソッドが多い場合、2つ目のクラスがメインクラス内に隠れている可能性があります）。

これらの非常に大まかな見積もりをまとめると：

• ソースファイルごとに最大1つのクラス。
• クラスごとに最大10個のパブリックメソッド。
• クラスごとに最大10個のプライベートメソッド。
• メソッドごとに最大100行。

したがって、2000行を超えるソースファイルは、おそらく大きすぎて面倒になり始めています。

これは実際には非常に大まかな見積もりであり、これらの基準を体系的に実行しません（特に、適切なリファクタリングを行うのに十分な時間がないためです）。また、Martin Beckettが示唆したように、クラスがメソッドの大きなコレクションであり、クラスを小さくするためだけに何らかの人工的な方法でそれらを分割する意味がない場合があります。

とにかく、私の経験では、上記のパラメーターのいずれかが尊重されないと、ファイルは読み取り不能になり始めます（たとえば、6画面にわたる300行のメソッド本体、または5000行のコードを持つソースファイル）。

いいえ-コード行ではありません。ドライバーは論理グループにする必要があります。たとえば、1つの大きなファイルに複数のクラスがあってはなりません。

正当に数百のメソッド（たとえば3Dモデリングでは不可能ではない）を持っているクラスがある場合、それを任意のファイルに分割するのはあまり便利ではありません。これは、メモリが不足し、プロセッサの速度が低下したときにこれを実行する必要がありました-そして、それは苦痛であり、常に関数定義を検索していました。

その中のコードが保守不能になると。つまり、探しているメソッド/クラス/関数がそこにあるかどうか（そして編集/デバッグする必要があります）、コードを見ているだけではわかりません。

ただし、IDE /エディタの選択と機能は、この上限の実際の定量化に影響します。コードの折りたたみ、関数/メソッドのリスト、およびルックアップは、この開発シナリオが提示された瞬間に延期されます。

しかし、そうなったら、それを分割する時です。

別のビューを次に示します。ファイルサイズを制限する方法について質問しています。私の意見では、大きなコードファイルを非常に問題にしている要因はたくさんあると思います。コードファイルは巨大な場合もありますが、その内容は十分にクラスター化されており、サイズが重大な問題を引き起こさないように非常にクリーンなコードです。LOCが高いにもかかわらず、非常に読みやすい多くのファイルを見てきました。

LOCメトリックを利用する代わりに、履歴データを使用して、これらの大きなファイルでコードが破損する頻度を理解することを検討します。通常、その理由は、開発者が同じファイル内の関連する他の場所を確認し、十分な理解なしに「迅速な修正」メンタリティで変更を行う忍耐の時間がないためです。

より大きな危険は、コピー＆ペーストコードの存在です。コピーペーストコーディングは、当然LOCの成長もスピードアップします。LOCをマジックナンバーよりも低く保つよりも、コピーと貼り付けをなくすことがさらに重要だと思います。純粋なコピーアンドペーストに加えて、大きなファイルには2番目の危険性があります。それは機能の重複です。ファイルが大きいほど、同じファイルの他のセクションに既にあるスニペットを再実装する可能性が高くなります。

したがって、大きなファイルのバグ修正率（すべてのコミットに対するバグ修正コミットの比率）が低い限り、状況は許容範囲です。試してみてgit log、エラーに関連するコミットの数をざっと見てください。または、Softagramなど、自動的に分析および視覚化できるツールを使用します。

これを考慮してください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歳の子供には理解できますが、内容の面で適しているのは1人だけです。

私の考えでは、コードを書くことはできる限り5歳の子供にとって意味があるはずです。Cyclomatic Complexity開発者がコードを生成するときに考慮する必要がある重要な概念です。ライブラリを利用して作成し、機能とコードの再利用性を可能な限り強化します。このようにして、コードは記述されているよりも多くのボリュームを話すことができます。

私たちのほとんどはアセンブリコードを書いていません。ただし、コードのルートはアセンブリです。正しく行えば、10000行のアセンブリを検索するのは10000行のpythonよりも難しくなります。

ただし、一部の作業では500〜1000行の書き込みが必要です。コードの目標は、300行のクリーンなコードを書くことです。

開発者として、「指輪物語」を書きたいです。バグを取得し、「帽子をかぶった猫」を書くまでは。コーディングを自我の尺度にしないでください。物事を単純な方法で機能させるだけです。

開発者はコードを文書化することを望んでいません（私は文書化されたコードを個人的に愛しています。私はそれほど利己的ではありません）。だから、あなただけが理解/読むことができるコードを書かないでください。Cat in the Hatコードを書きます。

私たちは皆、あなたがJRR Tolkenであることを知っています（あなたの頭の中）。バグのないコードで証明するものは何もないことを忘れないでください。

比phorのもう一つの理由。

読者が富を広めすぎないでください。ひとまとまりのグループで作業していて、その全員が同じ大きなファイルを変更する必要がある場合、おそらくgitマージ地獄に陥るでしょう。

誰もがリベースが大好きです。

->誰も言わなかった！

TL; DR可読性に焦点を当てます。コードとヘルパーをできるだけ多くの行とファイルに広げます。1つのファイルに8個または9個のクラスをスローしないでください。コードが読みにくくなり、保守が難しくなります。大きな条件コードまたはループがある場合は、言語でサポートされている場合、それらをLambdasに変更することを検討してください。ユーティリティ関数は、コードを読みやすくするための優れた手段と考えてください。重い入れ子は避けてください。