关于include的习惯问题
初接触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配置复杂化等各种问题,代码阅读性也会变差。
请教大佬,我的观点正确吗?