1つのファイルにどのくらいのコードを入れるのですか？

Question

私は今日、人々が通常は1つのソースファイルにどれくらいのコードを持っていて、それを複数の小さなファイルに分割するかについて考えていました。

私は個人的に私のファイルをかなり小さく保つ傾向があります（C/C++で作業するときは、特にヘッダファイル）。つまり、私は一般的にファイルが1つのクラスまたは複数の関数を1つのファイルに持つので、ファイルは一般的に<500行です。しかし、関連するすべてのものは、通常、同じ名前空間を共有します。

一方、私が扱っているものの中には、できるだけ多くのものを1つのファイルに張り付けようとしているものがあります。

私は小さなファイルが好きです。変更は1つのコードを再コンパイルするだけでいいので、大規模なファイルではなく、特定の目的を持った小さなファイルに分割されたときにソースをナビゲートする方が簡単です。全体のこと。いくつかの大量のファイルに実質的な利点はありますか？

たとえば、私のパーティクルシステムは、system.h、emitter.h、load.h、particle.hなどに分かれており、それぞれに対応する.cppファイルがあります。しかし、いくつかのパーティクルシステムでは、ソース全体を1つの.hと.cpp 1000行にしているように見えます。

Answer 1

小さいファイルは、読みやすく理解しやすいです。しかし、クラスやソースファイルの行数に基づいてこの決定を下すことはできません。共通の機能を別のファイルに配置する必要がある場合は、コードを分割することを検討してください。また、コードの再利用を可能にします。

Answer 2

論理的にはソフトウェアモジュールを物理的に識別する必要があります。 したがって、責任に応じてクラス/関数を設計する必要があります。

CRCアプローチを使用して、各クラスの責任を識別できます。

Answer 3

コードが変更されることを期待していない場合は、巨大な1つのファイルをユーザーにとってより便利にすることができます。例えば、SQLiteはユーザが自分のビルドに簡単に組み込むことができるモノリシックソースファイルとしてコードを配布します。

しかし、開発中に言及した理由のために、また、複数のプログラマーがプロジェクトに取り組んでいるときに、RCSマージの問題がほぼ確実に発生するため、ひどい考えです。

Answer 4

私はプロジェクトのさまざまな部分を別々のファイルに分割しました。主にそれに関連付けられたコンパイル時に使用されます。リンクする必要があるCCファイル用のオブジェクトがすでに存在する場合、それらを最初から再コンパイルする必要はありません。

モノリシックなファイルと小さいファイルのどちらを使用するかは、チームの決定である必要があります。使用するタブ/スペースに関するガイドラインと同様に、チームの各プログラマーが次のようなコーディング規則に明記する必要があります。新しいコードをプロジェクトに追加します。

一部のプロジェクトでは、特にプロジェクトの一部を1つだけ使用すると、コード全体が実質的に役に立たなくなる場合があります。それは、あなたがプロと詐欺の重さを測るトレードオフであり、最終的にどちらがあなたのためにうまくいくかを決定する必要があります。

言い換えれば、多くの小さなファイルでは、PERFORCEに似たバージョン管理システムを使って複数の開発者が開発を容易にすることができます。変更すると、ある開発者は、他の開発者が別の開発者コードの

Answer 5

もちろん、自分自身を標準に限定することはできません。しかし、私はあなたがスクロールせずにそれに何が起こるかを見ることができるように

あなたの方法は、メソッドにパラメータが少ないまたは7に等しい、とあなたの相続深さでなければなりません

、ワイド画面であることを記事で読んで人間が難なく理解するのに適した量である3以下でなければならない。

私の意見では、ファイルの制限はその責任であるべきです。各ファイルには独自のクラスが必要で、各クラスには1つの責任があります。

Answer 6

それぞれのソースファイルが少なすぎると、あまりにも多くなるほど悪くなります。混乱は、個々のソースファイル内からプロジェクト自体に移動するだけです。

ソースファイルが2つ（またはそれ以上）の明確に別々の側面を扱うようになったとき、私はそれを分割する傾向があります。

将来的に多く変更される可能性が高い機能が含まれていて、安定している可能性が高い機能が含まれているという感覚がある場合は、それを分割します。