关于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配置复杂化等各种问题,代码阅读性也会变差。

请教大佬,我的观点正确吗?

...全文
716 26 打赏 收藏 转发到动态 举报
AI 作业
写回复
用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,而是尽量入乡随俗。
liups 2019-09-01
  • 打赏
  • 举报
回复
在一个问题不支持楼主:楼主的想法是比较适合把共用代码什么的放在项目的子文件夹下面,但是这种方案不是很适合多个项目共用的情形(或者说同时开发多个项目的情况)
super_admi 2019-09-01
  • 打赏
  • 举报
回复
因为大家都是懒人
这些年,我极少在Windows编程里看到有人include多层子目录的,而Linux下可能是因为库的头文件本身固化了几个文件夹结构,则会出现include多层的情况。所以说,这里怎么搞,就看怎么做能更“懒”。

引用 4 楼 圣殿骑士18 的回复:
看来大家倾向还是比较明显啊
lin5161678 2019-09-01
  • 打赏
  • 举报
回复
项目引用的库发生变更 多加了一层
这时候 需要修改路径了
比如是
xxxxx/xxxx.h
现在需要分成
xxxxx/x86/xxxx.h
xxxxx/x64/xxxx.h
你的做法需要把每一个.c文件的include 都过一遍
makefile修改配置直接完成 哪种做法好不是显然的么
圣殿骑士18 2019-09-01
  • 打赏
  • 举报
回复
看来大家倾向还是比较明显啊
加载更多回复(8)

65,186

社区成员

发帖
与我相关
我的任务
社区描述
C++ 语言相关问题讨论,技术干货分享,前沿动态等
c++ 技术论坛(原bbs)
社区管理员
  • C++ 语言社区
  • encoderlee
  • paschen
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
  1. 请不要发布与C++技术无关的贴子
  2. 请不要发布与技术无关的招聘、广告的帖子
  3. 请尽可能的描述清楚你的问题,如果涉及到代码请尽可能的格式化一下

试试用AI创作助手写篇文章吧