C++プロジェクトのソースコードのレイアウト

Question

プロジェクトディレクトリを整理する一般的な方法の一つは、多かれ少なかれ、このようなものです同じディレクトリにあります。名前の衝突を避けるため、ファイル名には会社名やライブラリ名の接頭辞が付いていることがよくあります。 MyLibはMyAppのヘッダー検索パスなどに置かれます。私はファイル名の前に付くファンではありませんが、#includeを見て、そのヘッダーファイルがどこに属しているか正確に知るのが好きです。私はファイルを整理するこのアプローチが嫌いではありませんが、もっと良い方法があるはずです。

私は新しいプロジェクトを開始しているので、いくつかのディレクトリ構成のアイディアを求めたいと思います。 （即時ライブラリにのみ表示）

#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がその時々のlibと呼ばれている）srcディレクトリの下に格納されています

 
ProjA 
    +--include 
      +--ProjA 
        +--mylib 
          +--class_a.h 
        +--app 
          +--other_class.h 
    +--src 
     +--mylib 
       +--class_a.cpp 
        library_private_helpers.h 
        library_private_helpers.cpp 
     +--app 
       +--other_class.cpp 
       app.cpp 
       util.h 

app.cpp：現在、私は、このディレクトリ構造が好き。パブリックヘッダファイルは、project/libディレクトリ構造に編成され、<ProjectName/LibraryName/headerName.h>を介してインクルードされます。ファイル名の先頭には何も付いていません。他のチームで使用するためにMyLibをパッケージ化する必要があった場合は、makefileを変更して適切なバイナリファイルとインクルード/ ProjAディレクトリ全体をコピーするだけです。

ファイルがソースコントロールにチェックインされ、ファイルに対する作業が開始されると、ディレクトリ構造を変更することは難しくなります。それはすぐに取得する方が良いです。

このようなソースコードの作成経験がある人は誰ですか？あなたはそれについて好きではないものは何ですか？もしあなたがそれを行うより良い方法を持っているなら、私はそれについてよく聞きたいと思います。

Answer 1

さて、これらのプロジェクトの規模によって異なります。いくつかのファイルしか持っていない場合は、それらをすべて1つのフォルダに入れてください。

あなたが管理するファイルがたくさんないときは、フォルダが多すぎると私の意見では過剰です。あなたがそれらの中にいくつかのファイルしか持っていないとき、それは迷惑なフォルダの掘り出しになります。

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

実際には、すべてのものを1つのフォルダに保存しておくと、管理できない部分が見つかるまで再構築してから、ソースをフォルダに分割するという巧妙な仕組みに再編成します。あなたはおそらくあなたが走っている問題からどのように組織化する必要があるか知っているでしょう。

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

#include <MyLib/ClassA.h> 

：

Answer 2

私は両方の方法を試しました。個人的に、私は最初の方が好きです。もっと具体的なディレクトリにすべてを入れるという衝動を理解していますが、それは過剰な複雑さを引き起こします。

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

Answer 3

はなぜのみMyLibは愚かな接頭辞を減らすincludeディレクティブの一部として存在するディレクトリを使用し、最初のような何かを行うことはありません。 2番目の選択については、ヘッダーやソースファイルを開いたときに私は個人的には本当に迷惑になり、ディレクトリ構造を突き破って他を探して開きます。 2番目の例では、src/mylib/class_a.cppが開いていて、ヘッダーを編集したい場合は、多くのエディターで2つのレベルに戻ってから、ヘッダーを見つける前にinclude/ProjAに戻ってください。ヘッダーが他の外部の手がかりなしでProjAサブディレクトリにあることをどのようにして知ることができますか？さらに、あるファイルまたは他のファイルが別の場所に移動するのは容易ではなく、代替ファイルを移動することなく、そのファイルがどのように使用されているかを表します。私の職場でそれに遭遇したときには頭がおかしくなります（私が言及したすべての潜在的な問題を人々が行ったコードベースの一部を持っています）。