看来大家倾向还是比较明显啊

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

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

看来大家倾向还是比较明显啊

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

我觉得你可能在“代码阅读性”这一点上，有点钻牛角尖了。

任何一个方面的突出，很可能会导致其它方面的不突出，正所谓此消彼长。代码阅读性确实很重要，也有很多大神、大师在不断强调这一点，不过，你得知道为什么这些人要强调：那是因为很多时候，为了赶进度，项目中就忽略了“代码阅读性”这一条，毕竟项目中，首要的，还是完成任务，交付代码。

但是，代码阅读性虽然是我们要注意的，但其它方面也是我们需要在意的，比如，开发效率，开发进度，运行效率……等等。如果你把过多的精力，放在了代码的阅读性上，可能会导致其它方面的萎缩。假如，我们将0定为代码完全不可读，100定为代码完全可读，那么，必然有一个中间数值，是满足大多数代码阅读需求的，而我认为，你可能追求的是99可读，所以我说你钻牛角尖了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我是花心的射手座