8

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

我的库
     +--mylib_class_a.h
        mylib_class_a.cpp
        mylib_library_private_helpers.h
        mylib_library_private_helpers.cpp

我的应用
     +--other_class.h
        other_class.cpp
        应用程序.cpp

app.cpp：

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

同一个库的所有.h和.cpp文件都在同一个目录中。为避免名称冲突，文件名通常以公司名称和/或库名称作为前缀。MyLib 将位于 MyApp 的头文件搜索路径等中。我不喜欢为文件名添加前缀，但我喜欢查看#include并确切知道该头文件所属位置的想法。我不讨厌这种组织文件的方法，但我认为应该有更好的方法。

由于我正在开始一个新项目，因此我想征求一些目录组织的想法。目前我喜欢这个目录结构：

项目
    +--包括
             +--项目
                    +--mylib
                           +--class_a.h
                    +--应用程序
                           +--other_class.h
    +--src
         +--mylib
                +--class_a.cpp
                   library_private_helpers.h
                   library_private_helpers.cpp
         +--应用程序
              +--other_class.cpp
                 应用程序.cpp
                 实用程序.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

好吧，这一切都取决于这些项目有多大。如果您只有几个文件，则将它们全部放在一个文件夹中。

在我看来，当您没有太多要管理的文件时，太多的文件夹是矫枉过正的。当您只有几个文件时，在文件夹中挖掘和挖掘会很烦人。

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

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

KISS 通常是编程中的解决方案 -> 让一切尽可能简单。

于 2009-05-22T22:33:35.957 回答
4

为什么不做第一个类似的事情，只使用MyLib包含指令的一部分的目录，这减少了愚蠢的前缀：

#include <MyLib/ClassA.h>

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

于 2009-05-22T22:41:35.037 回答
3

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

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

于 2009-05-22T22:28:15.953 回答