私は通常、ソース コードを整理するために IDE や言語構文を使用しない(のみ) ことをお勧めします。1 つは、自分自身を環境に縛り付けることです。IDE で適切に整理され、ファイルが整理されていない場合、別の環境を使用したくなる日が来ます...
このため、私は通常、ソースを整理する 3 つの方法をすべて同時に使用します。ソースを機能モジュール、つまり関連するクラスに分割します。各モジュールは、独自の名前空間、物理フォルダー、および IDE フォルダーを取得します。(私の場合、CMakeを使用しsource_group()
、必要に応じて IDE プロジェクト ファイルを生成します。個人的には、コマンド ライン、Vim、および「make」を好みます。)
したがって、プロジェクトを IDE 内、コマンド ライン、またはコンパイラ ログのいずれから見ても、foo/some_class.hpp は foo/some_class.cpp は foo::some_class であり、混乱を最小限に抑えます。
実際、私の現在の好みの設定では、クラスが独自のモジュールの外部で使用されているかどうかに応じて、<project>/<module>/<class>.hpp
各モジュール ディレクトリをさらに 、 、およびに細分化しています。もちろん、名前空間はです。<project>/<module>/src/<class>.hpp
<project>/<module>/src/<class>.cpp
<project>/<module>/test/<class>_tu.cpp
<project>::<module>::<class>
project
|-- foo
| |-- some_class.hpp
| |-- src
| | |-- internal_class.hpp
| | |-- internal_class.cpp
| | `-- some_class.cpp
| `-- test
| |-- internal_class_tu.cpp
| `-- some_class_tu.cpp
|-- bar
| |-- ...
ここでの考え方は、各モジュールの「外部」インターフェース ( foo
) がそのサブフォルダーのヘッダーによって文書化され、実装の詳細とテストがそれぞれのサブフォルダーに「隠されている」ということです。
しかし、最終的には、あなたの好み、共同開発者の好み、およびプロジェクトの範囲に大きく依存します。