Question

组织项目目录的一种流行方式或多或少是这样的：

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

MyApp
     +--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
    +--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：

#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目录。

一旦将文件检入源代码控制并且人们开始处理它们，将很难更改目录结构。最好在开始时把它弄好。

有经验组织这样的源代码的人吗？你不喜欢什么吗？如果你有更好的方法，我非常想听听它。

Answer 1

嗯，这完全取决于这些项目有多大。如果您只有几个文件，那么将它们全部打包在一个文件夹中。

当你没有很多文件需要管理时，太多的文件夹在我看来太过分了。当你只有几个文件时，它会很烦人地进出文件夹。

此外，这取决于谁在使用这些东西。如果你正在编写一个库并且它将被其他程序员使用，那么将他们想要使用的头文件组织成一个包含文件夹是很好的。如果您要创建多个库并将它们全部发布，那么您的结构可能会起作用。但是，如果它们是独立的库，并且开发并非全部一起完成并且它们在不同时间进行版本化和发布，那么最好坚持将一个项目的所有文件都放在一个文件夹中。

事实上，我会说将所有内容保存在一个文件夹中，直到找到无法管理的位置，然后重新组织成一个聪明的方案，将源分成像你一样的文件夹。您可能知道如何根据遇到的问题组织起来。

KISS通常始终是编程的解决方案 - ＆gt;保持一切尽可能简单。

Answer 2

为什么不像第一个那样做，只使用MyLib所在的目录作为include指令的一部分，这减少了愚蠢的前缀：

#include <MyLib/ClassA.h>

告诉你他们来自哪里。至于第二种选择，当我打开标题或源文件时，我个人非常恼火，并且必须浏览目录结构以找到另一个并打开它。在第二个示例中，如果您打开了src/mylib/class_a.cpp，并且想要编辑标题，那么在许多编辑器中，您必须返回两个级别，然后在找到标题之前进入include/ProjA。我们怎么知道标题在ProjA子目录中而没有其他一些外部线索？另外，一个文件或另一个文件太容易移动到另一个“更好”代表它的使用方式的地方，而不移动备用文件。当我在工作中遇到它时，它让我感到头痛（我们的代码库中有一些部分让人们解决了我刚才提到的所有潜在问题）。

Answer 3

我尝试了两种方法。就个人而言，我更喜欢第一个。我理解将所有内容放在更具体的目录中的冲动，但它会导致很多过度复杂化。

我通常使用此规则：应用程序和内部库使用第一种方法。公共开源库使用第二种方法。当您发布代码时，如果包含文件位于单独的目录中，则会有很大帮助。

C ++项目源代码布局

3 个答案: