据说，这是一份来自菊厂的嵌入式 C 语言编码规范

我是老温，一名热爱学习的嵌入式工程师
关注我，一起变得更加优秀！
作为程序开发者，避免不了阅读别人代码，那么就会涉及到到一门语言的编程规范。规范虽然不是语言本身的硬性要求，但是已经是每一个语言使用者约定俗成的一个规范。
按照编程规范编写的代码，至少在代码阅读时，给人一种愉悦的心情，特别是强迫症患者。另一方面，统一的编程风格，可以减少编写错误，利于后期维护。
因为最近又开始进行纯C语言的开发，并且是基于SDK的开发，所以添加的每一行代码都应该与原来风格保持一致，不能因为一颗老鼠屎坏了一锅汤。一个良好的编程规范也可以看出编程人员的细心程度与代码质量。
之前待过的两家公司，也都有各自总结的编程规范，但都不约而同的一致，适用本公司的软件开发。这几天有幸可以参阅华为技术有限公司的C语言编程规范，相比之下，写的更加详细。
至少接触到了，在这个编程规范中体现了，并且还扩充了很多，我觉得有必要归纳总结，一遍日后查阅。先是学习规范，然后再积累规范，最后才是依规范编写。
1、清晰第一清晰性是易于维护、易于重构的程序必需具备的特征。代码首先是给人读的,好的代码应当可以像文章一样发声朗诵出来。
2.、简洁为美简洁就是易于理解并且易于实现。代码越长越难以看懂，也就越容易在修改时引入错误。写的代码越多，意味着出错的地方越多，也就意味着代码的可靠性越低。因此，我们提倡大家通过编写简洁明了的代码来提升代码可靠性。废弃的代码(没有被调用的函数和全局变量)要及时清除，重复代码应该尽可能提炼成函数。
3、选择合适的风格，与代码原有的风格保持一致产品所有人共同分享同一种风格所带来的好处，远远超出为了统一而付出的代价。在公司已有编码规范的指导下，审慎地编排代码以使代码尽可能清晰，是一项非常重要的技能。如果重构/修改其他风格的代码时，比较明智的做法是根据现有代码的现有风格继续编写代码,或者使用格式转换工具进行转换成公司内部风格。
一、头文件 原则1.1 头文件中适合放置接口的声明,不适合放置实现。
说明:头文件是模块(Module)或单元(Unit)的对外接口。头文件中应放置对外部的声明,如对外提供的函数声明、宏定义、类型定义等。
原则1.2 头文件应当职责单一。
说明:头文件过于复杂，依赖过于复杂是导致编译时间过长的主要原因。很多现有代码中头文件过大，职责过多，再加上循环依赖的问题，可能导致为了在.c中使用一个宏，而包含十几个头文件。
原则1.3 头文件应向稳定的方向包含。
说明:头文件的包含关系是一种依赖，一般来说，应当让不稳定的模块依赖稳定的模块，从而当不稳定的模块发生变化时，不会影响(编译)稳定的模块。
规则1.1 每一个.c文件应有一个同名.h文件,用于声明需要对外公开的接口。
说明:如果一个.c文件不需要对外公布任何接口，则其就不应当存在，除非它是程序的入口，如main函数所在的文件。
规则1.2 禁止头文件循环依赖。
说明:头文件循环依赖，指a.h包含b.h，b.h包含c.h，c.h包含a.h之类导致任何一个头文件修改，都导致所有包含了a.h/b.h/c.h的代码全部重新编译一遍。
而如果是单向依赖，如a.h包含b.h，b.h包含c.h,而c.h不包含任何头文件，则修改a.h不会导致包含了b.h/c.h的源代码重新编译。
规则1.3 .c/.h文件禁止包含用不到的头文件。
说明:很多系统中头文件包含关系复杂，开发人员为了省事起见,可能不会去一一钻研，直接包含一切想到的头文件，甚至有些产品干脆发布了一个god.h,其中包含了所有头文件，然后发布给各个项目组使用，这种只图一时省事的做法，导致整个系统的编译时间进一步恶化,并对后来人的维护造成了巨大的麻烦。
规则1.4 头文件应当自包含。
说明:简单的说，自包含就是任意一个头文件均可独立编译。如果一个文件包含某个头文件，还要包含另外一个头文件才能工作的话，就会增加交流障碍，给这个头文件的用户增添不必要的负担。
规则1.5 总是编写内部#include保护符(#define 保护)。
说明:多次包含一个头文件可以通过认真的设计来避免。如果不能做到这一点，就需要采取阻止头文件内容被包含多于一次的机制。
注: 没有在宏最前面加上 _ ，即使用 FILENAME_H代替  FILENAME_H ，是因为一般以 _ 和  __ 开头的标识符为系统保留或者标准库使用，在有些静态检查工具中，若全局可见的标识符以 _ 开头会给出告警。
定义包含保护符时，应该遵守如下规则:
1)保护符使用唯一名称;
2)不要在受保护部分的前后放置代码或者注释。
规则1.6 禁止在头文件中定义变量。
说明:在头文件中定义变量，将会由于头文件被其他.c文件包含而导致变量重复定义。
规则1.7 只能通过包含头文件的方式使用其他.c提供的接口,禁止在.c中通过extern的方式使用外部函数接口、变量。
说明:若a.c使用了b.c定义的foo()函数，则应当在b.h中声明extern int foo(int input)；并在a.c中通过#include 来使用foo。禁止通过在a.c中直接写extern int foo(int input)；来使用foo，后面这种写法容易在foo改变时可能导致声明和定义不一致。这一点我们因为图方便经常犯的。
规则1.8 禁止在extern "C"中包含头文件。
说明:在extern "C"中包含头文件，会导致extern "C"嵌套，Visual Studio对extern "C"嵌套层次有限制，嵌套层次太多会编译错误。
建议1.1 一个模块通常包含多个.c文件,建议放在同一个目录下,目录名即为模块名。为方便外部使用者,建议每一个模块提供一个.h,文件名为目录名。
建议1.2 如果一个模块包含多个子模块,则建议每一个子模块提供一个对外的.h,文件名为子模块名。
建议1.3 头文件不要使用非习惯用法的扩展名,如.inc。
建议1.4 同一产品统一包含头文件排列方式。
二、函数 原则2.1 一个函数仅完成一件功能。
说明:一个函数实现多个功能给开发、使用、维护都带来很大的困难。
原则2.2 重复代码应该尽可能提炼成函数。
说明:重复代码提炼成函数可以带来维护成本的降低。
规则2.1 避免函数过长,新增函数不超过50行(非空非注释行)。
说明:本规则仅对新增函数做要求，对已有函数修改时，建议不增加代码行。
规则2.2 避免函数的代码块嵌套过深,新增函数的代码块嵌套不超过4层。
说明:本规则仅对新增函数做要求，对已有的代码建议不增加嵌套层次。
规则2.3 可重入函数应避免使用共享变量;若需要使用,则应通过互斥手段(关中断、信号量)对其加以保护。
规则2.4 对参数的合法性检查,由调用者负责还是由接口函数负责,应在项目组/模块内应统一规定。缺省由调用者负责。
规则2.5 对函数的错误返回码要全面处理。
规则2.6 设计高扇入,合理扇出(小于7)的函数。
说明:扇出是指一个函数直接调用(控制)其它函数的数目,而扇入是指有多少上级函数调用它。如下图：