华为C语言通用编程规范.docx

《华为C语言通用编程规范.docx》由会员分享，可在线阅读，更多相关《华为C语言通用编程规范.docx（65页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、章节内容0前言目的重点关注约定例外1原那么好代码的原那么类和函数设计指导原那么保证静态类型平安遵循C+ ISO标准优先编译时检查错误使用命名空间来限定作用域优先使用C+特性而 不是c特性2命名通用命名文件命名函数命名类型命名变量命名宏、常量、枚举命名3格式 行宽缩进大括号函数声明和定义函数调用if语句循环语句switch语句 表达式变量赋值初始化指针和引用编译预处理空格和空行类4注释注释风格文件头注释函数头注释代码注释5头文件头文件职责头文件依赖6作用域 命名空间全局函数和静态成员函数全局变量全局常量和静态成员常量7类构造、拷贝构造、赋值和析构函数继承多重继承重载8函数 函数设计内联函数函数参

2、数9 C+其常量与初始化表达式类型转换资源分配和释放标准库const的用法异常他特性 模板宏10现代 代码简洁性和平安性提升智能指针Lambda接口C+特性。前言目的规那么并不是完美的，通过禁止在特定情况下有用的特性，可能会对代码实现造成影 响。但是我们制定规那么的目的为了大多数程序员可以得到更多的好处 如果 在团队运作中认为某个规那么无法遵循，希望可以共同改进该规那么。参考该规范之前，希望您具有相应的C+基础能力，而不是通过该文档来学习C+。1 ,了解C+的ISO标准；2.熟知C+的基本语言特性，包括C+ 03/11/14/17相关特性；3.了解C+的标准库；重点关注约定C+的编程风格，比方

3、命名，排版等。1 C+的模块化设计，如何设计头文件，类，接口和函数。2 C+相关特性的优秀实践，比方常量，类型转换，资源管理，模板等。3 现代C+的优秀实践，包括C+11/14/17中可以提高代码可维护性，提高代 码可靠性的相关约定。class MyClass public:MyClass() : value(0) private: int value;；函数声明和定义规那么函数声明和定义的返回类型和函数名在同一行；函数参数列 表超出行宽时要换行并合理对齐在声明和定义函数的时候，函数的返回值类型应该和函数名在同一行；如果行宽度 允许，函数参数也应该放在一行；否那么，函数参数应该换行，并进行合理

4、对齐。参数列表的左圆括号总是和函数名在同一行，不要单独一行；右圆括号总是跟随最 后一个参数。换行举例：ReturnType FunctionName(ArgType paramNamel ArgType paramName2) / Good：全在同一行ReturnType VeryVeryVeryLongFunctionName(ArgType paramNamel/ 行宽不满足所有参数,进行换行ArgType paramNameZ.,/ Good：和上一行参数对齐ArgType paramName3) )ReturnType LongFunctionName(ArgType paramNam

5、el ArgType paramNameZ / 行宽限制,进行换行ArgType paramName3., ArgType paramName4j ArgType paramName5) / Good:换行后4空格缩进 )ReturnType Really Really Really Rea HyLongFunctionName(/ 行宽不满足第1个参数,直接换行ArgType paramNamel ArgType paramName2, ArgType paramName3) / Go od:换行后4空格缩进函数调用规那么函数调用入参列表应放在一行，超出行宽换行时，保持参数 进行合理对齐函数

6、调用时，函数参数列表放在一行。参数列表如果超过行宽，需要换行并进行合 理的参数对齐。左圆括号总是跟函数名，右圆括号总是跟最后一个参数。换行举例：ReturnType result = FunctionName(paramNamel., paramName2); / Good： 函 数参数放在一行/ Good：保/ Good：保/ Good：参/行宽不满/换行后,4ReturnType result = FunctionName(paramNamel paramName2 持与上方参数对齐paramName3);ReturnType result = FunctionName(paramName

7、lJ paramName2 paramName3j paramName4 paramName5);数换行,4空格缩进ReturnType result = VeryVeryVeryLongFunctionName( 足第1个参数,直接换行paramNamel paramName2, paramName3);空格缩进如果函数调用的参数存在内在关联性，按照可理解性优先于格式排版要求，对参数 进行合理分组换行。/ Good；每行的参数代表一组相关性较强的数据结构,放在一行便于理解一int result = DealWithStructureLikeParams（left .x., left.y/ 表

8、示一组的关参数一right.X, right.y）; / 表示另外 一组相关参数if语句规那么3.6.1 if语句必须要使用大括号我们要求if语句都需要使用大括号，即便只有一条语句。理由：-代码逻辑直观，易读；-在已有条件语句代码上增加新代码时不容易出错;对于在if语句中使用函数式宏时，有大括号保护不易出错（如果宏定义时遗漏了 大括号）。if (objectlsNotExist) / Good：单行条件语句也加大括号return CreateNewObject();)规那么禁止if/else/else if写在同一行条件语句中，假设有多个分支，应该写在不同行。如下是正确的写法：if (some

9、Conditions) DoSomething(); else / Good: eLse 与 if 在不同行 )下面是不符合规范的案例：if (someConditions) else / Bad: eLse 与 if 在同一行循环语句规那么循环语句要求使用大括号和if语句类似，我们要求for/while循环语句必须加上的大括号，即使循环体是空 的，或者循环语句只有一条。for (int i = 0; i someRange; i+) DoSomething();)如果循环体是空的，应该使用空的大括号，而不是使用单个分号。单个分号容易 被遗漏，也容易被误认为是循环语句中的一局部。for (in

10、t i = 0; i someRange; i+) / Good： for 循环体是空,使用大 括号,而不是使用分号while (someCondition) / Good： while循环体是空,使用大括号,而不是使 用分号while (someCondition) continue; / Good： continue表示空逻辑,可以使用大括号也可以不使用)坏的例子：for (int i = 0; i threshold & / Good：换行后,逻辑操作符放在行尾 someConditionsion) DoSomething(); )int result = reallyReallyLon

11、gVariableNamel +/ GoodreallyReallyLongVariableName2;表达式换行后，注意保持合理对齐，或者4空格缩进。参考下面例子int sum = longVaribleNamel + longVaribleName2 + longVaribleName3 + longVaribleName4 + longVaribleName5 + longVaribleName6;/Good: 4空格缩进int sum = longVaribleNamel + longVaribleName2 + longVaribleName3 + longVaribleName4

12、+ longVaribleName5 + longVaribleName6; /Good:保持对齐变量赋值规那么多个变量定义和赋值语句不允许写在一行每行只有一个变量初始化的语句，更容易阅读和理解。int maxCount = 10;bool isCompleted = false;下面是不符合规范的例如：int maxCount = 10; bool isCompleted = false; / Bad：多个变量初始化需要分 开放在多行,每行一个变量初始化int x, y = 0; / Bad：多个变量定义需要分行,每行一个int pointX;int pointY; pointX = 1;

13、pointY = 2; / Bad：多个变量赋值语句放同一行例外：for循环头、if初始化语句(C+17) 结构化绑定语句(C+17)中可以声 明和初始化多个变量。这些语句中的多个变量声明有较强关联，如果强行分成多行 会带来作用域不一致，声明和初始化割裂等问题。初始化初始化包括结构体、联合体、及数组的初始化规那么初始化换行时要有缩进，并进行合理对齐结构体或数组初始化时，如果换行应保持4空格缩进。从可读性角度出发，选择 换行点和对齐位置。const int rank = 16, 16, 16, 16, 32, 32, 32, 32,64, 64, 64, 64, 32, 32, 32, 32；指

14、针与引用建议指针类型”跟随变量名或者类型，不要两边都留有或者都没有空格指针命名：*靠左靠右都可以，但是不要两边都有或者都没有空格。int* p = NULL; / Good int *p = NULL; / Good int*p = NULL; / Bad int * p = NULL; / Bad例外：当变量被const修饰时，钎无法跟随变量，此时也不要跟随类型。char * const VERSION = VlOO;建议引用类型&跟随变量名或者类型，不要两边都留有或者都没有空格引用命名：&靠左靠右都可以，但是不要两边都有或者都没有空格。int i = 8;/ Good/ Good/ Bad

15、/ Bad/ Good/ Good/ Bad/ Badint& p = i; int &p = i;int & p = i;int&p = i;编译预处理规那么编译预处理的“阴统一放在行首，嵌套编译预处理语句时，“# 不缩进编译预处理的“铲统一放在行首，即使编译预处理的代码是嵌入在函数体中的，# 也应该放在行首。#if defined( x86 64 ) & defined( GCC HAVE SYNC COMPARE AND SWAP 16)/ Good：放在行首#define ATONIIC_X86_HAS_CMPXCHG16B 1 / Good： “井”放在行首#else#define

16、ATONIIC_X86_HAS_CMPXCHG16B 0#endifint FunctionName() if (someThingError) / Good：即便在函数内部,斯”也放在行首#ifdef HAS_SYSLOG WriteToSysLog();#elseWriteToFileLog();#endif ) )内嵌的预处理语句“ # 不缩进#if definedf x86 64 ) & defined( GCC HAVE SYNC COMPARE AND SWAP 16) ttdefine AT0MIC_X86_HAS_CMPXCHG16B 1 / Good：区分层次,便于阅读 #e

17、lse#define AT0MIC_X86_HAS_CMPXCHG16B 0#endif空格和空行建议水平空格应该突出关键字和重要信息，防止不必要的留白水平空格应该突出关键字和重要信息，每行代码尾部不要加空格。总体规那么如下: if, switch, case, do, while, for 等关键字之后加空格；小括号内部的两侧，不要加空格； 大括号内部两侧有无空格，左右必须保持一致；一元操作符(&* + -！)之后不要加空格； 二元操作符(= + -*/% |&A =!=)左右两侧加空格三目运算符(?:)符号两侧均需要空格 前置和后置的自增、自减(+-)和变量之间不加空格结构体成员操作符(.

18、，)前后不加空格 逗号C)前面不加空格，后面增加空格对于模板和类型转换(v)和类型之间不要添加空格 域操作符(:)前后不要添加空格冒号(:)前后根据情况来判断是否要添加空格常规情况：void Foo(int b) / Good：大括号前应该留空格 int i = 0; / Good：变量初始化时,=前后应该有空格，分号前面不要留空格int bufkBufSize = 0;/ Good：大括号内两侧都无空格函数定义和函数调用: int result = Foo(arglJarg2);A / Bad:逗号后面需要增加空格int result = Foo( argl arg2 );AA /Bad:函

19、数参数列表的左括号后面不应该有空格,右括号前面不应该有空格指针和取地址x = *p;/ Good： *操作符和指针p之间不加空格p=&x;/ Good： &操作符和变量x之间不加空格x =r.y； / Good：通过.访问成员变量时不加空格义= r-y; / Good：通过- 访问成员变量时不加空格操作符:x = 0；/ Good：赋值操作的 =前后都要加空格x = -5；/ Good：负数的符号和数值之前不要加空格+x；/ Good：刖置和后置的+/-和变量之间不要加空格X-； if (x & !y) / Good：布尔操作符前后要加上空格，！操作和变量之间不要空格v = w*x + y/z

20、; / Good：二元操作符前后要加空格v = w * (x + z);/ Good：括号内的表达式前后不需要加空格int a = (x y) ? x : y; / Good:三目运算符,?和:前后需要添加空格循环和条件语句:if (condition) / Good：讨关键字和括号之间加空格,括号内条件语句前后不加 空格 else / Good： else关键字和大括号之间加空格 )while (condition) / Good： lAihiLe关键字和括号之间加空格,括号内条件语句前后不加空格for (int i = 0; i )不与空格紧邻, 和(之间也没有. vector x;y =

21、 static_cast(x);/在类型与指针操作符之间留空格也可以,但要保持一致.vector x;域操作符std: :cout; / Good:命名空间访问,不要留空格int MyClass: :GetValue() const / Good:对于成员函数定义,不要留空格 冒号/添加空格的场景/ Good:类的派生需要留有空格class Sub : public Base ;/构造函数初始化列表需要留有空格MyClass:MyClass(int var) : someVar(var) DoSomething();)/位域表示也留有空格struct XX char a :4; char b

22、:5; char c :4；/不添加空格的场景/ Good:对于pubLic: private:这种类访问权限的冒号不用添加空格class MyClass public:MyClass(int var);private:int someVar;； /对于switch-case的case和default后面的冒号不用添加空格switch (value) case 1:DoSomething();break;default:break;)注意：当前的集成开发环境(IDE)可以设置删除行尾的空格，请正确配置。建议合理安排空行，保持代码紧凑减少不必要的空行，可以显示更多的代码，方便代码阅读。下面有一些

23、建议遵守的 规那么：-根据上下内容的相关程度，合理安排空行；-函数内部、类型定义内部、 宏内部、初始化表达式内部，不使用连续空行-不使用连续3个空行，或更多-大 括号内的代码块行首之前和行尾之后不要加空行。int Foo() / Bad：两个函数定义间超过了一个空行 int Bar() )if (.) / Bad：大括号内的代码块行首不要加入空行 / Bad：大括号内的代码块行尾不要加入空行 int Foo()/ Bad：函数体内行首不要加空行约定规那么：编程时必须遵守的约定(must) 建议：编程时应该遵守的约定(should)本规范适用通用C+标准,如果没有特定的标准版本，适用所有的版本

24、(C+03/ll/14/17)o例外无论是规那么还是建议都必须理解该条目这么规定的原因，并努力遵守。但是, 有些规那么和建议可能会有例外。在不违背总体原那么，经过充分考虑，有充足的理由的前提下，可以适当违背规范中 约定。例外破坏了代码的一致性，请尽量防止。规那么的例外应该是极少的。以下情况，应风格一致性原那么优先：修改外部开源代码、第三方代码时，应该遵守开源代码、第三方代码已有规范，保持风格统一。某些特定领域，优先参考其行业规范。好代码的原那么我们参考Kent Beck的简单设计四原那么来指导我们的如何写出优秀的代码，如何有 效地判断我们的代码是优秀的。1.通过所有测试(Passes its

25、tests) 2.尽可能消除 重复(Minimizes duplication) 3.尽可能清晰表达(Maximizes clarity) 4.更少代码元 素(Has fewer elements) 5.以上四个原那么的重要程度依次降低。这组定义被称做简 单设计原那么。第一条强调的是外部需求，这是代码实现最重要的；第二点就是代码的模块架构设 计，保证代码的正交性，保证代码更容易修改；第三点是代码的可阅读性，保证代 码是容易阅读的；最后一点才是保证代码是简洁的，在简洁和表达力之间，我们更 看重表达力。类和函数设计指导原那么C+是典型的面向对象编程语言，软件工程界已经有很多OOP原那么来指导我们编

26、 写大规模的，高可扩展的，可维护性的代码：高内聚，低耦合的基本原那么- SOLID原那么-迪米特法那么-Tell, Dont ask”原那么-组合/聚合复用原那么规那么3.154类访问控制块的声明依次序是public:, protected:, private:,每个都缩进1个空格class MyClass : public BaseClass public: /注意没有缩进 MyClass(); /标准的4空格缩进 explicit MyClass(int var);MyClass() void SomeFunction();void SomeFunctionThatDoesNothing(

27、) )void SetVar(int var) someVar = var; int GetVar() const return someVar; private:bool SomeInternalFunction();int someVar;int someOtherVar;；在各个局部中，建议将类似的声明放在一起，并且建议以如下的顺序:类型(包括 typedef, using和嵌套的结构体与类),常量,工厂函数,构造函数,赋值运算符,析构函 数，其它成员函数,数据成员。规那么构造函数初始化列表放在同一行或按四格缩进并排多行/如果所有变量能放在同一行:MyClass:MyClass(int

28、var) : someVar(var) DoSomething();)/如果不能放在同一行,/必须置于冒号后,并缩进4个空格MyClass:MyClass(int var):someVar(var)., someOtherVar(var + 1) / Good:逗号后而留有空格 DoSomething();)/如果初始化列表需要置于多行,需要逐行对齐MyClass:MyClass(int var):someVar(var),/ 缩进4 个空格someOtherVar(var + 1) DoSomething();)4注释一般的，尽量通过清晰的架构逻辑，好的符号命名来提高代码可读性；需要的时候,

29、 才辅以注释说明。注释是为了帮助阅读者快速读懂代码，所以要从读者的角度出 发，按需注释。注释内容要简洁、明了、无二义性，信息全面且不冗余。注释跟代码一样重要。写注释时要换位思考，用注释去表达此时读者真正需要的 信息。在代码的功能、意图层次上进行注释，即注释解释代码难以表达的意图，不 要重复代码信息。修改代码时，也要保证其相关注释的一致性。只改代码，不改注 释是一种不文明行为，破坏了代码与注释的一致性，让阅读者迷惑、费解，甚至误解。注释风格在C+代码中，使用/* */和/都是可以的。按注释的目的和位置，注释可分为不 同的类型，如文件头注释、函数头注释、代码注释等等；同一类型的注释应该保持统 一的

30、风格。注意：本文例如代码中，大量使用后置注释只是为了更精确的描述问题，并 不代表这种注释风格更好。文件头注释规那么文件头注释必须包含版权许可/* Copyright (c) 2019 name of copyright hoLder* Software Name is Licensed under the Mu Lan PSL vl.* You can use this software according to the terms and conditions of t he Mu Lan PSL vl.* You may obtain a copy of Mu Lan PSL vl at:

31、* THIS SOFTIaIARE IS PROVIDED ON AN nAS IS BASIS, WITHOUT WARRANTIES OF ANY KIND, EITHER EXPRESS OR* IMPLIED, INCLUDING BUT NOT LIMITED TO NON-INFRINGEMENTj MERCHANTABIL ITY OR FIT FOR A PARTICULAR* PURPOSE.* See the Mu Lan PSL vl for more detaiLs.*/函数头注释规那么禁止空有格式的函数头注释并不是所有的函数都需要函数头注释；函数签名无法表达的信息，加

32、函数头注释 辅助说明；函数头注释统一放在函数声明或定义上方，使用如下风格之一：使用写函数头/单行函数头int Funcl(void);/多行函数头/第二行int Func2(void);使用/*/写函数头/*单行函数头*/int Funcl(void);/*另一种单行函数头*/int Func2(void);*多行函数头*第二行*/int Func3(void);函数尽量通过函数名自注释，按需写函数头注释。不要写无用、信息冗余的函数 头；不要写空有格式的函数头。函数头注释内容可选，但不限于：功能说明、返回值，性能约束、用法、内存约定、 算法实现、可重入的要求等等。模块对外头文件中的函数接口声明

33、，其函数头注 释，应当将重要、有用的信息表达清楚。例：* 返回实际写入的字节数，-1表示写入失败* 注意,内存buf由调用者负责释放* /int WriteString(const char *buf, int len);坏的例子:* 函数名:lAlriteString* 功能:写入字符串* 参数:* 返回值:* /int WriteString(const char *buf, int len);上面例子中的问题：* 参数、返回值，空有格式没内容函数名信息冗余* 关键的buf由谁释放没有说清楚代码注释规那么441代码注释放于对应代码的上方或右边规那么442注释符与注释内容间要有1空格；右置注

34、释与前面代码至少1空格代码上方的注释，应该保持对应代码一样的缩进。选择并统一使用如下风格之一: 使用/这是单行注释DoSomething();/这是多行注释/第二行DoSomething();/*这是单行注释*/DoSomething();/ * 另一种方式的多行注释* 第二行* /DoSomething();代码右边的注释，与代码之间，至少留1空格，建议不超过4空格。通常使用扩 展后的TAB键即可实现1-4空格的缩进。选择并统一使用如下风格之一:int foo = 100; /放右边的注释int bar = 200; /*放右边的注释*/右置格式在适当的时候，上下对齐会更美观。对齐后的注释，

35、离左边代码最近的那一行，保证1-4空格的间隔。例：const int kConst = 100;/*相关的同类注释,可以考虑上下对齐*/const int kAnotherConst = 200;/*上下对齐时,与左侧代码保持间隔*/当右置的注释超过行宽时，请考虑将注释置于代码上方。规那么443不用的代码段直接删除，不要注释掉被注释掉的代码，无法被正常维护；当企图恢复使用这段代码时，极有可能引入易 被忽略的缺陷。正确的做法是，不需要的代码直接删除掉。假设再需要时，考虑移植 或重写这段代码。这里说的注释掉代码，包括用/*/和，还包括#ifO, #ifdef NEVER-DEFINED 等等。建议

36、441正式交付给客户的代码不能包含TODO/TBD/FIXME注释TODO/TBD注释一般用来描述待改进、待补充的修改点FIXME注释一般用来 描述缺陷它们都应该有统一风格，方便文本搜索统一处理。如：/ TODOf ）:补充XX 处理/ FIXME: XX 缺陷5头文件头文件职责头文件是模块或文件的对外接口，头文件的设计表达了大局部的系统设计。头文 件中适合放置接口的声明，不适合放置实现（内联函数除外）。对于cpp文件中 内部才需要使用的函数、宏、枚举、结构定义等不要放在头文件中。头文件应当 职责单一。头文件过于复杂，依赖过于复杂还是导致编译时间过长的主要原因。建议每一个.cpp文件应有一个对

37、应的.h文件，用于声明需要对外 公开的类与接口通常情况下，每个.cpp文件都有一个相应的.h,用于放置对外提供的函数声明、宏 定义、类型定义等。如果一个.cpp文件不需要对外公布任何接口，那么其就不应当 存在。例外：程序的入口（如main函数所在的文件），单元测试代码，动态库 代码。例如：/ Foo.h #ifndef FOO_Hftdefine FOO_Hclass Foo public:Foo();void Fun();private:int value;；#endif/ Foo.cpp#include “Foo.h”namespace / Good:对内函数的声明放在.cpp文件的头部,

38、并声明为匿名namespa ce或者static限制其作用域void Bar() void Foo:Fun() Bar();)头文件依赖规那么禁止头文件循环依赖头文件循环依赖，指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的源代码重新编译。头文件循环依赖直接表达了架构设计上的不合理，可通过优化架构去防止。规那么522禁止包含用不到的头文件用不到的头文件被包含的同时

39、引入了不必要的依赖，增加了模块或单元之间的耦合 度，只要该头文件被修改，代码就要重新编译。很多系统中头文件包含关系复杂，开发人员为了省事起见，直接包含一切想到的头 文件，甚至发布了一个god.h,其中包含了所有头文件，然后发布给各个工程组使 用，这种只图一时省事的做法，导致整个系统的编译时间进一步恶化，并对后来人 的维护造成了巨大的麻烦。规那么头文件应当自包含简单的说，自包含就是任意一个头文件均可独立编译。如果一个文件包含某个头文 件，还要包含另外一个头文件才能工作的话，给这个头文件的用户增添不必要的负 担。例如：如果a.h不是自包含的，需要包含b.h才能编译，会带来的危害：每个使用 a.h头

40、文件的.cpp文件，为了让引入的a.h的内容编译通过，都要包含额外的头文 件b.ho额外的头文件b.h必须在a.h之前进行包含，这在包含顺序上产生了依赖。规那么524头文件必须编写#define保护，防止重复包含为防止头文件被重复包含，所有头文件都应当使用#define保护；不要使用#pragma once定义包含保护符时，应该遵守如下规那么：1）保护符使用唯一名称；2）不要在受 保护局部的前后放置代码或者注释，文件头注释除外。例如：假定VOS工程的timer模块的timer.h,其目录为VOS/include/timer/Timer.h,应按如下方式保护：ftifndef VOS_INCLU

41、DE_TIMER_TIMER_H#define VOS_INCLUDE_TIMER_TIMER_H #endif也可以不用像上面添加路径，但是要保证当前工程内宏是唯一的。#ifndef TIMER_Hftdefine TIMER_H #endif建议521禁止通过声明的方式引用外部函数接口、变量只能通过包含头文件的方式使用其他模块或文件提供的接口。通过extern声明的 方式使用外部函数接口、变量，容易在外部接口改变时可能导致声明和定义不一致。 同时这种隐式依赖，容易导致架构腐化。不符合规范的案例：/ a.cpp 内容extern int Fun(); / Bad:通过extern的方式使用外

42、部函数void Bar() int i =Fun(); )/ b.cpp 内容int Fun() / Do something应该改为：/ a.cpp 内容ftinclude b.h1/ Good:通过包含头文件的方式使用其他.cpp提供的接口void Bar() int i =Fun(); )b.h内容int Fun();/ b.cpp 内容int Fun() / Do something例外，有些场景需要引用其内部函数，但并不想侵入代码时，可以extern声明方 式引用。如：针对某一内部函数进行单元测试时，可以通过extern声明来引用被测 函数；当需要对某一函数进行打桩、打补丁处理时，允

43、许extern声明该函数。规那么525禁止在extern C中包含头文件在extern C”中包含头文件,有可能会导致extern C”嵌套,局部编译器对extern “C嵌套层次有限制，嵌套层次太多会编译错误。在C, C+混合编程的情况下，在extern中包含头文件，可能会导致被包含头文件的原有意图遭到破坏，比方链接规范被不正确地更改。例如，存在a.h和b.h两个头文件：/ a.h内容 #ifdef_cplusplusvoid Foo(int);#define A(value) Foo(value)#elsevoid A(int)#endif/ b.h内容 #ifdef_cplusplusextern HC #endif#include a.h void B();#ifdef_cplusplus) 一#endif使用C+预处理器展开b.h,将会得到extern C voidFoo(int); voidB()；)按照a.h作者的本意，函数Foo是一个C+自由函数，其链接规范为“C+”。但在 b.h中，由于#include ”a.h“被放到了 extern的内部，函数Foo的链接规范被不正确地更改了。例外：如果在C+编译环