c - C项目文件和模块化组织

Question

C项目文件和模块化组织
  
  我一直在搜索，找不到C项目组织的合理答案（没有新程序员的技术术语的示例）。
  
  我可能没有搜索专门的词来描述这一点，因此遇到了问题。 （重构，模块化编程和项目组织？）
  
  关于如何组织项目的示例，我只是对标头定义层次结构和源/标头文件之间的范围感到困惑。


--main.c--

#include “project_headers.h”

int main(void)
{
    int errorCode = runProgram();
    if(errorCode != 0)
    {
        storeError(“Error while running program”, errorCode);
    }
return errorCode;
}

--project_headers.h--

#include <SDL.h>
#include <stdio.h>
// and any other header I might need

--runprogram.c--

#include “project_headers.h”

int runProgram()
{
    int running = 1;
    int errorCode = 0;

    if(initialize() == 1)
    {
        errorCode = 5567;
        storeError(“Error while initializing”, errorCode);
        running = 0;
    {

    while(running == 1)
    {
        if(events() != 0)....  //.... = same as initialize() but different error codes
        if(logic() != 0)....
        if(render() != 0)....
    {
    if(cleanupAndShutdown() != 0)....
    return errorCode;
}

--initialize.c--

#include “project_headers.h”
int initSDLstuff()
{
}

int initWindow()
{
}

int initialize()
{
    int errorCode = 0;
    if(initSDLstuff() != 0)....
    if(initWindow() != 0)....
    return errorCode;
}

这个粗略行不通，我尝试过。未定义引用的问题超出范围等

我是第一时间和正确思考问题的忠实拥护者，并深入阅读主题，文章，K＆R风格之类的辩论，甚至是像K＆R风格这样的辩论都是唯一的选择。

我不希望这变成一个自以为是的答案，并将尝试缩小范围。

我希望我在“ C”语言中的编码要现代，模块化，简单而优雅

我希望能够在教程之外编写任何团队，员工或人类都可以看得出来的代码！太好了，我想修改X，一切仍然正常。

我在寻找一些不错的源代码以供参考，人们说要看“ Doom”或Linux内核，发现对我的经验来说，它们有点过头，也许不是“现代”风格。

我不是在寻找那些过于模糊和难以理解的超级优化代码。如果有人知道伟大的“ C”的任何引用，那么只有伟大的项目。我可能会感兴趣的一些示例项目是图像加载器/保存器，计算器，简单的3D模型查看器，能够保存和加载的简单文本编辑器。我已经看过很多源代码，但是对于一个没有经验的程序员来说，很难说出什么是好的和坏的做法，我真的不想纠正坏的习惯。

很抱歉这个冗长的问题，并尽我所能将其范围缩小，以至于没有理由。

1. C项目文件和模块化组织？ （可以使用我的示例代码作为示例）

2.具有现代，模块化，简单且优雅的性质的好的简单C项目/源代码？

谢谢

Answer 1

这是项目布局的非技术性解释。

（1.）可以简化所有术语以保持代码的清洁，可读性和可维护性，因此导航100,000（或1,000,000）行源代码不会干扰您的编码思考过程。如果您迷失了源代码，那么该考虑将内容配对并在单独的文件中放置类似的代码了。

（2.）去哪里？好吧..，把逻辑上相关的东西放在一起。如果您的项目比较短，那么可能根本不需要拆分代码。另一方面，如果您使用抽象数据结构进行数据处理（例如linked-list等），则有必要将数据处理结构拆分为单独的标头和源，这样您就可以主要的源代码并没有杂乱的1000行列表操作代码。如果这是一个具有与轨道力学有关的功能的科学项目，那么将这些程序分开也是有意义的。基本规则是将东西放在一起-放在一起。这不仅提高了可维护性，而且还提高了可重用性。如果您有另一个项目需要相同的轨道力学例程，则可以重用已经创建的源和标题，而不必每次都重新设计轮子。

（3.）随着您的自定义代码库的增长，可能有必要在自己的文件中开始将类似的函数分组在一起，以后可以将其转换为库，也可以随时使用。如果您有提供binary output representation和/或处理过的bit operations的函数集合，那么将它们组合在一起可能很有意义。与您的file/directory例程相同。与您的string manipulations例程相同。最重要的是，任何逻辑分组对您而言都是有意义的，并有助于使代码保持整洁和可维护性，从而使代码保持在一起。

（4.）另一个考虑因素是数据隐藏/保护和功能访问。通过将数据分成单独的标头，可以在C中某种程度上控制是否通过标头包含使数据可用，哪些功能和哪些源文件可以访问哪些数据。有关可使用程度的极端示例，请参见Object oriented programming with ANSI-C。

（5.）什么时候拆分这些东西？同样，在这里，当您开始一个项目时，您可能已经分解了那些打算使用的零件，引入了这些零件，或者发现自己基本上是从1个文件中进行原型制作。随着文件的增长，当您花了很多精力去搜索/搜索文件中的functionX或variableY时，现在该是时候看看是否可以清理代码并简化工作了，将类似的代码收集到一个单独的文件中。你是法官。如果您是能够在不丢失逻辑流，位置等信息的情况下进行100,000条线切割/切块的人之一，那么您将不会在很久以后到达“收集并分离出来可能有意义”的观点相对于其它的。这是为您工作的。

还有其他考虑因素，无疑还有6-500个问题，但这就是为什么要在各种头文件和源文件之间拆分代码的原因。在学习时，您经常会看到一些示例，这些示例很好地说明了文件之间的代码分割，没有其他原因，但表明可以在文件后面进行处理。如果您在3个函数和2个变量中有27行代码，则没有理由拆分任何内容，但是您会发现一个例子，一个例子接一个例子，只是为了说明可以分割数据和代码的方法。这并不意味着您在到达第28行时就需要开始拆分。做对自己有用的事情。