关于include的习惯问题

圣殿骑士18 2019-08-31 07:11:25

初接触c/c++，看公司其他员工之前写的c代码。因为公司写的c代码，主要是用于嵌入式，是在各种板卡比如stm32，arm上，写c代码，因此代码规模不是很大，比如就十几二十个c文件。我看到c代码文件中，对其他头文件的引用，也是跟我过往的习惯不同。

我之前都是用高级语言开发的，比如c#，java，JavaScript，这些语言中的类引用，大家都是用带路径的类路径。
而我们公司的c/c++项目往往是平铺式引用，比如：
#include "privilege.h"，
虽然privileg文件是在其他目录下，但include却是不带子目录的。当然编译和调试也不是问题，因为通过makefile配置可解决。

但作为一个一直写c#,Java的人来说，感觉更好的引用方式，应该是在include中包含子目录，比如这样：
#include <iostream>
#include <stdio.h>
#include "Shared/cJSON/cJSON.h"
#include "IniDb/IniDb.h"
#include "OmxProt/OmxProtMng.h"

对于我来说，认为这是当然的，因为这样代码描述性，阅读性是最强的。
但对于做嵌入式开发的工程师来说，似乎不太认同我的观点，他们习惯于将include写为单一层级，然后通过定义makefile来解决编译路径问题。

我个人的观点是，
对于小规模的嵌入式代码，可能就是几个代码文件，怎么都行。
但如果是在linux arm上做开发，要实现大规模的代码，比如几百上千个文件，如果只使用平铺式的include，可能造成同名文件冲突，或者造成makefile配置复杂化等各种问题，代码阅读性也会变差。

请教大佬，我的观点正确吗？

...全文

718 26 打赏收藏转发到动态举报

写回复

用AI写文章

26 条回复

切换为时间正序

请发表友善的回复…

发表回复

RivenDong 2019-09-06

打赏
举报

我觉得是因为一开始行业不同所导致的

赵4老师 2019-09-05

打赏
举报

引用 24 楼圣殿骑士18 的回复:

[quote=引用 20 楼赵4老师的回复:] [quote=引用 19 楼走好每一步的回复:] 楼主有点钻牛角尖了，include这个阅读影响真不大。。。

万一楼主是追求极致完美的处女座呢？

[/quote] 我是花心的射手座

[/quote] 没准你妈妈对你的出生年月日隐瞒了什么。

无心和尚 2019-09-05

打赏
举报

这头文件不影响阅读函数代码吧？

luj_1768 2019-09-05

打赏
举报

权限不一样。服务能力和响应方式也不一样。

赵4老师 2019-09-04

打赏
举报

百万军中取上将首级如探囊取物，

千万行里改关键源码在弹指瞬间。

圣殿骑士18 2019-09-04

打赏
举报

引用 20 楼赵4老师的回复:

[quote=引用 19 楼走好每一步的回复:]
楼主有点钻牛角尖了，include这个阅读影响真不大。。。

万一楼主是追求极致完美的处女座呢？

[/quote]
我是花心的射手座

nice_cxf 2019-09-04

打赏
举报

其实都行，好多源码也是包含子目录的，include一个相对路径也很正常，甚至linux的库文件很多都是带了子目录这种没必要统一风格，

sunny7862632 2019-09-04

打赏
举报

只能说楼主没有写过C的项目，include写上路径才是大坑。当一个模块要平行移植到另外一个项目时，部分路径变了，然后每个c文件都要修改一遍。而且做嵌入式来说，这种移植算是比较常见的方式了，每次都这样玩，写代码的估计会骂娘。

轻箬笠 2019-09-04

打赏
举报

很少见到include带完整相对路径的，只带一层相对路径的倒是相对常见一些。
我觉得这是C/C++的编程风格问题，楼主没必要纠结于此，一定觉得java的引入风格比较好。而且ide基本上按快捷键直接跳转到文件的，关注include的路径没多大意思。
还有个问题，我觉得如果带路径，以后重新规划模块，会不会改动比较多哦？

赵4老师 2019-09-04

打赏
举报

引用 19 楼走好每一步的回复:

楼主有点钻牛角尖了，include这个阅读影响真不大。。。

万一楼主是追求极致完美的处女座呢？

走好每一步 2019-09-04

打赏
举报

楼主有点钻牛角尖了，include这个阅读影响真不大。。。

圣殿骑士18 2019-09-03

打赏
举报

引用 16 楼赵4老师的回复:

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。

意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。

试对比
图书馆（对图书的分类够结构化了吧）
和
搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索）
哪个处理信息更方便、更高效。

所以
与其费劲去重构代码让其看上去更简洁、更合理
不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。

结构越复杂，越难修改，越难除错。
有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。

程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George

前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题：
◆“要保证这个问题不会再出现，我该怎么做？”
◆“要想少出些Bug，我该怎么做？”
◆“要保证Bug容易被修复，我该怎么做？”
◆“要保持对变化的快速响应，我该怎么做？”
◆“要保证我的软件的运行速度，我该怎么做？”
如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

赵4老师角度刁钻。这是修正代码的正确方向，需多看几遍。
赵老师看代码犹如庖丁解牛般，又或像一个给病人做手术的医生，手到即病除，妙手定回春。
有空学习下grep、sed、awk。。。

赵4老师 2019-09-02

打赏
举报

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。试对比图书馆（对图书的分类够结构化了吧）和搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索）哪个处理信息更方便、更高效。所以与其费劲去重构代码让其看上去更简洁、更合理不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。结构越复杂，越难修改，越难除错。有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George 前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题： ◆“要保证这个问题不会再出现，我该怎么做？” ◆“要想少出些Bug，我该怎么做？” ◆“要保证Bug容易被修复，我该怎么做？” ◆“要保持对变化的快速响应，我该怎么做？” ◆“要保证我的软件的运行速度，我该怎么做？” 如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

uouo88 2019-09-02

打赏
举报

引用 14 楼圣殿骑士18 的回复:

我提到的代码可阅读性，其实提到不等于强调。就像我说一个东西有10个优点，这个代码可阅读性可能就是第10个优点，它的比重是不高。不是说代码可阅读性不重要，而是include对代码的可阅读性上影响小。

同时，为什么我提出代码可阅读性呢？因为我在看别人的代码。当你在看别人的代码的时候，include中如果能明确引用地址，是不是能带来一些方便？当然这带来的方便性也是小的，反正代码编辑器能够通过链接跳转，基本上解决了找代码的问题。

我能理解，但是习惯吧，毕竟C++是一个有着悠久历史的语言，它得考虑到和C语言的兼容性等方方面面的问题，包袱比较重，语法和其它高级语言不同也很正常，没必要深究。

圣殿骑士18 2019-09-01

打赏
举报

引用 5 楼 lin5161678 的回复:

项目引用的库发生变更多加了一层
这时候需要修改路径了
比如是
xxxxx/xxxx.h
现在需要分成
xxxxx/x86/xxxx.h
xxxxx/x64/xxxx.h
你的做法需要把每一个.c文件的include 都过一遍
makefile修改配置直接完成哪种做法好不是显然的么

有些道理，makefile提供了灵活性。我的观点，可能还是因为我对makefile不熟悉所致。

圣殿骑士18 2019-09-01

打赏
举报

引用 6 楼 super_admi 的回复:

因为大家都是懒人
这些年，我极少在Windows编程里看到有人include多层子目录的，而Linux下可能是因为库的头文件本身固化了几个文件夹结构，则会出现include多层的情况。所以说，这里怎么搞，就看怎么做能更“懒”。

引用 4 楼圣殿骑士18 的回复:
看来大家倾向还是比较明显啊

哈哈。懒是一个巨大的动力。
怎么理解懒，也很重要。我对理解“懒”包含这一点：代码的阅读性，维护性要好，这样才能支持我以后能“懒”一点来维护系统，能“躺”着维护就不要“站”着维护，甚至于“绑着沙袋”维护。

另外一点，我对语言和它们所衍生出的开发环境，是能理解的。每种语言当前的一些编程习惯和做法，往往和其本身的特性相关，很可能就是最优选择。对这一点，我能够给与足够的理解。所以，我也不会强制要求用C#和java的风格来要求c/c++，就像我不以java风格来要求c#，也不以c#风格来要求java，而是尽量入乡随俗。