8

プロジェクト ディレクトリを整理する一般的な方法の 1 つは、多かれ少なかれ次のようなものです。

MyLib
     +--mylib_class_a.h
        mylib_class_a.cpp
        mylib_library_private_helpers.h
        mylib_library_private_helpers.cpp

マイアプリ
     +--other_class.h
        other_class.cpp
        app.cpp

app.cpp:

#include "other_class.h"
#include <mylib_class_a.h> // using library MyLib

.h同じライブラリのファイルはすべて.cpp同じディレクトリにあります。名前の衝突を避けるために、ファイル名には多くの場合、会社名やライブラリ名がプレフィックスとして付けられます。MyLib は MyApp のヘッダー検索パスなどに含まれます。私はファイル名にプレフィックスを付けるのは好きではありませんが#include、ヘッダー ファイルがどこに属しているかを正確に把握するために、. ファイルを整理するこのアプローチは嫌いではありませんが、もっと良い方法があるはずだと思います。

新しいプロジェクトを開始するので、ディレクトリ構成のアイデアを募集したいと思います。現在、私はこのディレクトリ構造が好きです:

ProjA
    +--含む
             +--ProjA
                    +--mylib
                           +--class_a.h
                    +--アプリ
                           +--other_class.h
    +--src
         +--mylib
                +--class_a.cpp
                   library_private_helpers.h
                   library_private_helpers.cpp
         +--アプリ
              +--other_class.cpp
                 app.cpp
                 util.h

app.cpp:

#include "util.h" // private util.h file
#include <ProjA/app/other_class.h> // public header file
#include <ProjA/mylib/class_a.h> // using class_a.h of mylib
#include <other3rdptylib/class_a.h> // class_a.h of other3rdptylib, no name collision
#include <class_a.h> // not ProjA/mylib/class_a.h
#include <ProjA/mylib/library_private_helpers.h> // error can't find .h

.cppファイルとプライベート (即時ライブラリにのみ表示される).hファイルは、src ディレクトリ (src は lib と呼ばれることもあります) の下に格納されます。パブリック ヘッダー ファイルは project/lib ディレクトリ構造に編成され、<ProjectName/LibraryName/headerName.h>. ファイル名の前に何も付けません。他のチームが使用できるように MyLib をパッケージ化する必要が生じた場合は、makefile を変更して、適切なバイナリ ファイルと include/ProjA ディレクトリ全体をコピーするだけで済みます。

ファイルがソース管理にチェックインされ、人々がファイルの作業を開始すると、ディレクトリ構造を変更するのは難しくなります。初めのうちはきちんとしたほうがいいです。

このようなソース コードを整理した経験のある人はいますか? 気に入らない点はありますか？もっと良い方法があれば、ぜひ教えていただきたいです。

4

3 に答える 3

8

まあ、それはすべて、これらのプロジェクトの大きさに依存します. ファイルが数個しかない場合は、それらすべてを 1 つのフォルダーにまとめます。

管理するファイルが多くないのにフォルダが多すぎるのは、私の意見ではやり過ぎです。フォルダにいくつかのファイルしか入っていない場合、フォルダを調べたり調べたりするのは面倒です。

また、誰がこのようなものを使用しているかによって異なります。ライブラリを作成していて、それを他のプログラマーが使用する場合は、プログラマーが使用するヘッダーをインクルード フォルダーにまとめるとよいでしょう。多数のライブラリを作成し、それらすべてを公開している場合、構造は機能する可能性があります。ただし、それらが独立したライブラリであり、開発がすべて一緒に行われるわけではなく、異なる時期にバージョン管理およびリリースされる場合は、1 つのプロジェクトのすべてのファイルを 1 つのフォルダー内に配置することに固執する方がよいでしょう。

実際、管理しきれなくなるまではすべてを 1 つのフォルダーに保管しておき、それからソースをフォルダーに分割する巧妙なスキームに再編成することをお勧めします。遭遇した問題から、それをどのように整理する必要があるかがわかります。

KISS は通常、常にプログラミングのソリューションです -> すべてをできるだけシンプルに保ちます。

于 2009-05-22T22:33:35.957 に答える
4

最初のようなことをしないのはなぜですかMyLib。インクルード ディレクティブの一部として存在するディレクトリのみを使用してください。これにより、ばかげたプレフィックスが削減されます。

#include <MyLib/ClassA.h>

それは彼らがどこから来たかを教えてくれます。2 番目の選択肢については、ヘッダー ファイルまたはソース ファイルを開いているときに、ディレクトリ構造を移動して別のファイルを見つけて開く必要があると、個人的には非常にイライラします。2 番目の例では、src/mylib/class_a.cpp開いていてヘッダーを編集したい場合、多くのエディターではinclude/ProjAヘッダーを見つける前に 2 つのレベルに戻る必要があります。そして、ヘッダーがProjA他の外部の手がかりのないサブディレクトリ？さらに、代替ファイルを移動せずに、どちらかのファイルを別の場所に移動するのは簡単すぎます。仕事で遭遇すると頭痛がするだけです（そして、私が言及したすべての潜在的な問題を人々が行ったコードベースのいくつかの部分があります）。

于 2009-05-22T22:41:35.037 に答える
3

私は両方の方法を試しました。個人的には前者の方が好きです。すべてをより具体的なディレクトリに配置したいという衝動は理解できますが、それは多くの複雑さを引き起こします。

私は通常、このルールを使用します。アプリケーションと社内ライブラリは最初の方法を使用します。パブリック オープン ソース ライブラリは、2 番目の方法を使用します。コードをリリースするとき、インクルード ファイルが別のディレクトリにあると非常に役立ちます。

于 2009-05-22T22:28:15.953 に答える