关于在 C 中组织代码文件的最佳文章 [关闭]答案

【问题标题】：best articles about organizing code files in C [closed]关于在 C 中组织代码文件的最佳文章 [关闭]
【发布时间】：2010-10-04 02:10:26
【问题描述】：

您能否推荐我应该阅读/学习什么才能在 C 中编写组织良好的代码？

我想学习的一件事是在.h和.c文件中拆分项目的原则，什么去哪里，为什么，变量命名，何时使用全局变量......

我对解决这个特定问题的书籍和文章感兴趣。

【问题讨论】：

标签： c code-organization

【解决方案1】：

Large Scale C++ Software Design, by John Lakos 是一本涵盖很多内容的好书（适用于 C 和 C++）：

另外，要记住的一个好的经验法则是“永远不要做任何在头文件中分配内存的事情”

【讨论】：

“永远不要在头文件中分配内存”---我喜欢这样。简洁明了，是智慧的明珠。
只是为了确保我做对了，在头文件中分配内存是一个问题，因为如果两个 .c 文件包含它，就会出现链接器歧义。我说的对吗？
只是想知道，您能否详细说明该经验法则？我可以理解它是否是静态分配（例如，前面没有 extern 的变量），但我真的不明白这是怎么回事，比如 malloc。
@Lazer - 是的@Edmund - 另一种看待我所说的方式是在 .h 文件中声明内容，不要定义它们。如果您在头文件中有一个正在初始化和 malloc 的变量，那么您就是在寻找潜在的麻烦。
我喜欢这句话：“永远不要做任何在头文件中分配内存的事情”。在一行中阐明其他人在该做和不该做的页面中尝试做的事情

【解决方案2】：

关于文件布局，没有太多选择。

分区通常是以下之一（这里的包是单个库或二进制文件）：

.../project/.../package/module.{c,h}
.../project/.../{src,include}/package/module.{c,h} // 非接口头文件转到 src
.../project/.../package/{src,include}/module.{c,h} // 非接口头文件转到 src

分区 (1) 很方便，因为属于特定包的所有文件都存储在一个目录中，因此可以轻松地移动包，但是通过这种方法将 API 标头与私有标头分离并检测 API 更改并非易事. (2) 和 (3) 非常相似，它们使 API 发布和 API 更改检测变得微不足道，而 (2) 在您总是发布整个项目的情况下稍微容易一些， (3) 当您发布单个包时稍微好一些（例如用于修补目的）

在任何 C/C++ 项目中，通常都有以下常用包：

常用宏和数据类型
日志包
应用程序引导程序包（如果有项目中有超过 1 个二进制文件）。

【讨论】：

【解决方案3】：

特定于 unix（而不是 c, natch），但仍然如此：

Recursive Make Considered Harmful

通过描述的构建结构，您可以负担使用大量文件。所以每个逻辑单元都有一个头文件和一个源文件。

【讨论】：

【解决方案4】：

我认为关于这个主题的最佳教育读物是阅读 Linux Kernel 源代码之类的东西。它有一个很好的源代码布局，基本上是标准的大型 C 项目。 Here 也是关于如何为 BSD 源代码组合源文件的指南。

说真的，刚开始阅读内核源代码并了解所有内容是如何组合在一起的。显然，这是一个精心策划的项目。

【讨论】：