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＆amp; R风格这样的辩论是与其他方式相比的唯一方式。
我不希望这会转向一个固执己见的答案，并试图缩小范围。
我希望能够在任何团队，员工或人类会看到并说出的教程之外编写代码！哇很好，我想修改X，一切都还可以。
我找了一些很好的参考源代码，人们说看看'Doom'或Linux内核，发现他们对我的经验有点过头了，也许不是那么'现代'的风格。
我不是在寻找那些只是模糊不清并且难以理解的超级优化代码。如果有人知道任何伟大的'C'的参考只有很棒的项目。我可能感兴趣的一些示例项目是图像加载器/保护程序，计算器，简单的3D模型查看器，能够保存和加载的简单文本编辑器。我看了很多源代码，但是对于没有经验的程序员来说，很难说出好的和坏的做法，我真的不想修复坏习惯。
很抱歉这个冗长的问题，并尽力缩小范围，以便它没有见解。
由于
答案 0 :(得分：1)
以下是项目布局的非技术性说明。
（1。）所有行话都可以归结为保持代码清洁，可读和可维护，因此导航100,000（或1,000,000）行源不会干扰你的编码思维过程。如果您迷失在源头，那么就该考虑将事情配对并将代码放在不同的文件中。
（2。）什么地方？嗯..，保持逻辑上相关的东西。如果您有一个简短的项目，那么可能根本不需要拆分代码。另一方面，如果您正在使用抽象数据结构进行数据处理（例如linked-list等），那么将数据处理结构和函数拆分为单独的头和源是有意义的。所以你的主要来源并没有杂乱的1000行列表操作代码。如果它是一个具有与轨道力学相关的功能的科学项目，那么将这些例程分开也是有意义的。基本规则将所有内容放在一起 - 一起使用。这不仅可以提升可维护性，还可以提升可重用性。如果你有另一个需要相同轨道力学程序的项目，你可以重复使用已经创建的源和头，而不是每次都重新发明轮子。
（3。）随着您的自定义代码库的增长，可以在自己的文件中开始将类似功能组合在一起，以后可以将其转换为库 ，或者你可以随时使用。如果您有一组提供binary output representation和/或已处理bit operations的函数，那么您可以将这些函数放在一起。与您的file/directory例程相同。与您的string manipulations例程相同。底线无论逻辑分组对您有意义，并帮助保持代码清洁和可维护性有意义保持在一起。
（4。）另一个考虑因素是数据隐藏/保护＆amp;功能访问。通过将数据拆分为单独的标题，您可以在某种程度上控制C中的哪些函数以及哪些源文件可以通过标头包含使数据可用来访问哪些数据。有关可以使用的程度的极端示例，请参阅Object oriented programming with ANSI-C。
（5。） 什么时候分手呢？这里再一次，当你开始一个项目时，你要么已经拆分了那些您计划使用，引入，或者您发现自己基本上是1个文件的原型。随着该文件的增长，当你到达脑力搜索/搜索文件中的functionX或variableY时，可能是时候查看是否可以清理代码并让生活更轻松将相似的代码收集到一个单独的文件中。你是法官。如果你是那些可以切割/切割100,000行但没有忘记逻辑流程，位置等的人之一，那么你将不会在以后找到“收集和分离可能有意义”相对于其它的。这对你有用。
还有其他一些注意事项，毫无疑问6-500更多，但这就是为什么要在各种标头和源文件之间拆分代码的问题。您经常在学习时看到示例，代码很好地分配在文件中，没有其他原因，但要显示它可以在它后面完成。如果在3个函数和2个变量中有27行代码，则没有理由将任何内容拆分，但是您会找到示例，例如，这样做 - 只是为了显示您可以做什么来划分数据和代码。这并不意味着当你遇到第28行时你需要开始分裂。这对你有用。
答案 1 :(得分：0)
答案相对简单，但细节取决于您，系统设计师：
include是一个通用名称）src是一个通用名称）makefile，