【程序的长相】 2 混乱不堪的main源文件

辛昕

【程序的长相】 2 混乱不堪的main源文件 [复制链接]

一般来说，我们已经很少写只有一个源文件的程序项目。
而所有c程序都从main（）开始执行。

我们习惯性把main()函数所在的源文件称为 主源文件。
但是，这一集的题目是 混乱不堪的 主源文件。

闲话少说，先上图。

辛昕

先问你一个问题
你能很快找出 main()函数在哪吗？

辛昕

我想，你是不太容易一眼找到main的，而且这个截图的作者还好，他给每个函数加了一条 行注释 分割线。
然而，main散杂在那么多的子函数里，要找到并不是一件容易的事。

而且这还是一个相当容易的模块演示程序。

如果这是一个复杂点的，比如我在simpliciTI peer-to-peer里见到的。
那就更加困难了。
另外，因为你需要阅读这个代码，你要理解他
或者你要修改它，那么，你势必需要经常在各个函数之间来回走，这个时候你会更加痛苦。
——没错，你可以 右键 go to definition.....找到函数的实现，但是你怎么回头？

任何会造成函数修改，维护，理解困难，麻烦的做法，都是不好的做法。
这是一个非常朴素的思想。

辛昕

换一个角度思考问题。
我们为什么要分那么多源文件？
哦，我们要模块化？
什么叫模块化？
这是个问题，而且你最好 仔细斟酌，当然，这是个很复杂的问题，最好在天长日久的开发中慢慢体会，那样才来的真实。
这个问题不在本帖讨论之列。

我只能作以下一些类比;

1.子函数，是为了让main函数更加短？
2.typedef重定义 unsigned char 为 UCHAR或者 U8，难道就是为了写少几个字母？

很多时候，我们在做一些自认为会让自己方便的事情。比如上述提到的第二点。

然而，如果把 方便 这个词 放在更长远，更广阔的范围里思考，我们就会知道，不加思索，纯粹为了一时乐得轻松的做法，往往得不偿失。

好了，回到 这个 混乱不堪的main源文件 问题。
我给这个问题的答案是
既然我们写这些子函数，来让我们的main函数变得更加简单，更加意义明确（而非涉及一堆无关紧要的底层实现），我们就是为了 更快的浏览main函数来了解整个程序 所做的事情。
我们还为每一个模块功能分了那么多源文件，那么，为什么我们不能再把这些子函数分到一个或者几个源文件里呢?
难道那样我们不是更容易在 看主函数 想进入某个子函数里看到更进一步的细节以后，继续回到main函数的下一个函数调用？
因为，那样做的话，我只需要轻轻点 那个名叫 main.c的源文件，就可以找到了那唯一一个main()函数。