[转载]GNU make 指南之三

时间：2005-12-20 来源：ghostzhu

1.2 何时分解你的项目

很明显，把任何东西都分解是不合理的。象“世界，你们好”这样的简单程序根本就不能分，因为实在也没什么可分的。把用于测试用的小程序分解也是没什么意思的。但一般来说，当分解项目有助于布局、发展和易读性的时候，我都会采取它。在大多数的情况下，这都是适用的。（所谓“世界，你们好”，既 'hello world' ，只是一个介绍一种编程语言时惯用的范例程序，它会在屏幕上显示一行 'hello world' 。是最简单的程序。）

如果你需要开发一个相当大的项目，在开始前，应该考虑一下你将如何实现它，并且生成几个文件（用适当的名字）来放你的代码。当然，在你的项目开发的过程中，你可以建立新的文件，但如果你这么做的话，说明你可能改变了当初的想法，你应该想想是否需要对整体结构也进行相应的调整。

对于中型的项目，你当然也可以采用上述技巧，但你也可以就那么开始输入你的代码，当你的码多到难以管理的时候再把它们分解成不同的档案。但以我的经验来说，开始时在脑子里形成一个大概的方案，并且尽量遵从它，或在开发过程中，随着程序的需要而修改，会使开发变得更加容易。

1.3 怎样分解项目

先说明，这完全是我个人的意见，你可以（也许你真的会？）用别的方式来做。这会触动到有关编码风格的问题，而大家从来就没有停止过在这个问题上的争论。在这里我只是给出我自己喜欢的做法（同时也给出这么做的原因）：

i) 不要用一个 header 文件指向多个源码文件（例外：程序包的 header 文件）。用一个 header定义一个源码文件的方式会更有效，也更容易查寻。否则改变一个源文件的结构（并且它的 header 文件）就必须重新编译好几个文件。

ii) 如果可以的话，完全可以用超过一个的 header 文件来指向同一个源码文件。有时将不可公开调用的函数原型，类型定义等等，从它们的Ｃ源码文件中分离出来是非常有用的。使用一个 header 文件装公开符号，用另一个装私人符号意味着如果你改变了这个源码文件的内部结构，你可以只是重新编译它而不需要重新编译那些使用它的公开 header 文件的其它的源文件。

iii) 不要在多个 header 文件中重复定义信息。如果需要，在其中一个 header 文件里 #include 另一个，但是不要重复输入相同的 header 信息两次。原因是如果你以后改变了这个信息，你只需要把它改变一次，不用搜索并改变另外一个重复的信息。

iv) 在每一个源码文件里， #include 那些声明了源码文件中的符号的所有 header 文件。这样一来，你在源码文件和 header 文件对某些函数做出的矛盾声明可以比较容易的被编译器发现。

相关阅读更多 +