1.1 C++编程规范总则 (5)
1.1.1 资料来源 (5)
1.1.2 C++编程规范总则 (6)
1. 原则：编程时必须坚持的指导思想。 (6)
2. 规则：编程时强制必须遵守的约定。 (6)
3. 建议：编程时必须加以考虑的约定。 (6)
4. 说明：对此原则/规则/建议进行必要的解释。 (6)
5. 示例：对此原则/规则/建议从好、不好两个方面给出例子。 (6)
6. 延伸阅读材料：建议进一步阅读的参考材料。 (6)
1.2 C++ 编程规范1 常量 (6)
1.2.1 资料来源 (6)
1.2.2 C++ 编程规范1 常量 (6)
1. 规则1.1 使用const常量取代宏 (6)
2. 规则1.2 一组相关的整型常量应定义为枚举 (6)
3. 规则1.3 不相关的常量，即使取值一样，也必须分别定义 (7)
4. 建议1.1 尽可能使用const (8)
1.3 C++编程规范2 初始化和类型转换 (8)
1.3.1 2.1 声明、定义与初始化 (8)
1. 规则2.1 禁止用memcpy、memset初始化非POD对象 (8)
2. 建议2.1 变量使用时才声明并初始化 (8)
3. 建议2.2 避免构造函数做复杂的初始化，可以使用“init”函数 (9)
4. 建议2.3 初始化列表要严格按照成员声明顺序来初始化它们 (9)
5. 建议2.4 明确有外部依赖关系的全局与静态对象的初始化顺序 (10)
1.3.2 2.2 类型转换 (10)
1. 规则2.2 使用C++风格的类型转换，不要使用C风格的类型转换 (10)
2. 建议2.5 避免使用reinterpret_cast (11)
3. 建议2.6 避免使用const_cast (11)
4. 建议2.7 使用虚函数替换dynamic_cast (11)
1.4 C++编程规范3 函数 (11)
1.4.1 3.1 内联函数 (11)
1. 规则3.1 内联函数(inline function)小于10行 (12)
2. 规则3.2 使用内联函数代替函数宏 (12)
3. 建议3.1 内联函数应该放在头文件中声明，而且在函数前添加inline关键字 (12)
4. 建议3.2 内联函数的实现放在独立的文件 (12)
1.4.2 3.2 函数参数 (13)
1. 建议3.3 入参尽量用const引用取代指针 (13)
2. 建议3.4 消除未使用函数参数 (13)
3. 建议3.5 尽量少用缺省参数 (13)
1.4.3 3.3 函数指针 (13)
1. 建议3.6 尽量少用函数指针 (13)
1.5 C++编程规范4 类 (13)
1.5.1 4.1 类的设计 (13)
1. 原则4.1 类职责单一 (14)
2. 原则4.2 隐藏信息 (14)
3. 原则4.3 尽量使类的接口正交、少而完备 (14)
4. 规则4.1 模块间对外接口类不要暴露私有和保护成员 (14)
5. 规则4.2 避免成员函数返回成员可写的引用或者指针 (15)
6. 规则4.3 禁止类之间循环依赖 (15)
7. 建议4.1 将数据成员设为私有的(struct除外)，并提供相关存取函数 (16)
8.建议4.2 使用PIMPL模式，确保私有成员真正不可见 (16)
1.5.2 4.2 构造、赋值和析构 (16)
1.规则4.4 包含成员变量的类，须定义构造函数或者默认构造函数 (16)
2. 规则4.5 为避免隐式转换，将单参数构造函数声明为explicit (17)
3. 规则4.6 包含资源管理的类应自定义拷贝构造函数、赋值操作符和析构函数 (17)
4. 规则4.7 让operator=返回*this的引用 (18)
5. 规则4.8 在operator=中检查给自己赋值的情况 (18)
6. 规则4.9 在拷贝构造函数、赋值操作符中对所有数据成员赋值 (19)
7. 规则4.10 通过基类指针来执行删除操作时，基类的析构函数设为公有且虚拟的 (19)
8. 规则4.11 避免在构造函数和析构函数中调用虚函数 (20)
9. 建议4.3 拷贝构造函数和赋值操作符的参数定义成const引用类型 (20)
10. 建议4.4 在析构函数中集中释放资源 (20)
1.5.3 4.3 继承 (20)
1. 原则4.4 用组合代替继承 (21)
2. 原则4.5 避免使用多重继承 (21)
3. 规则4.12 使用public继承而不是protected/private继承 (21)
4. 规则4.13 继承层次不超过4层 (21)
5. 规则4.14 虚函数绝不使用缺省参数值 (22)
6. 规则4.15 绝不重新定义继承而来的非虚函数 (22)
7. 建议4.5 避免派生类中定义与基类同名但参数类型不同的函数 (23)
8. 建议4.6 派生类重定义的虚函数也要声明virtual关键字 (23)
1.5.4 4.4 重载 (23)
1. 原则4.6 尽量不重载操作符，保持重载操作符的自然语义 (23)
2. 规则4.16 仅在输入参数类型不同、功能相同时重载函数 (24)
3. 建议4.7 使用重载以避免隐式类型转换 (24)
4. 建议4.8 C/C++混用时，避免重载接口函数 (24)
1.6 C++编程规范5 作用域、模板和C++其他特性 (24)
1.6.1 5.1 作用域 (25)
1. 原则5.1 使用名字空间进行归类，避免符号冲突 (25)
2. 规则5.1 不要在头文件中或者#include之前使用using指示符 (25)
3. 建议5.1 尽量少使用嵌套类(成员类) (26)
4. 建议5.2 尽可能不使用局部类 (26)
5. 建议5.3 使用静态成员函数或名字空间内的非成员函数，避免使用全局函数 (26)
6. 建议5.4 避免class类型的全局变量，尽量用单件模式 (26)
1.6.2 5.2 模板 (26)
1. 建议5.5 谨慎使用模板，只使用模板的基础特性 (27)
2. 建议5.6 注意使用模板的代码膨胀 (27)
3. 建议5.7 模板类型应该使用引用或指针 (27)
4. 建议5.8 模板如果有约束条件，请在模板定义处显式说明 (27)
5. 建议5.9 两个模块之间接口中尽量不要暴露模板 (27)
1.6.3 5.3 其他 (27)
1. 规则5.2 不要在extern "C"内部使用#include包含其他头文件 (27)
2. 建议5.10 避免使用友元 (27)
3. 建议5.11 避免使用RTTI (27)
4. 建议5.12 使用sizeof(变量)而不是sizeof(类型) (27)
1.7 C++ 6 资源分配和释放 (28)
1.7.1 资料来源： (28)
1.7.2 C++ 6 资源分配和释放 (28)
1. 原则6.1 明确产品动态内存的申请与释放原则 (28)
2. 规则6.1 明确operator new的行为和检查策略 (28)
3. 规则6.2 释放内存后，要立即将指针设置为NULL，防止产生野指针 (29)
4. 规则6.3 new单个对象删除使用delete，new[n]数组对象删除使用delete [] (29)
5. 规则6.4 释放结构(类)指针时，必须从底层向上层顺序删除 (29)
6. 规则6.5 释放指针数组时，首先释放数组每个元素指针所指向的内存 (30)
7. 规则6.6 不要返回局部对象指针 (31)
8. 规则6.7 不要强制关闭线程 (31)
9. 建议6.1 使用new, delete的封装方式来分配与释放内存 (31)
10. 建议6.2 避免在不同的模块中分配和释放内存 (32)
11.建议6.3 使用RAII 特性来帮助追踪动态分配 (32)
1.8 C++ 编程规范7 异常与错误处理 (33)
1.8.1 7.1 异常 (33)
1. 原则7.1 减少不必要的异常 (34)
2. 规则7.1 构造和析构函数不能抛出异常 (34)
3. 规则7.2 通过传值的方式抛出，通过引用的方式捕获 (34)
4. 规则7.3 确保抛出的异常一定能被捕捉到 (34)
5. 规则7.4 确保异常发生后资源不泄漏 (34)
6. 规则7.5 独立编译模块或子系统的外部接口禁止抛异常 (35)
1.8.2 7.2 错误处理策略 (35)
1. 原则7.2 建立合理的错误处理策略 (35)
2. 原则7.3 离错误最近的地方处理错误或转换错误 (35)
3. 规则7.6 错误发生时，至少确保符合基本保证；对于事务处理，至少符合强保证；对于原
子操作，符合无错误保证 (35)
1.9 C++编程规范8 标准库 (36)
1.9.1 资料来源 (36)
1.9.2 C++编程规范8 标准库 (36)
1. 规则8.1 避免使用auto_ptr (36)
2. 规则8.2 仅将scoped_ptr、shared_ptr和unique_ptr用于管理单个对象 (37)
3. 规则8.3 如果涉及循环引用，使用weak_ptr解开循环 (37)
4. 规则8.4 使用make_shared代替new生成shared_ptr (39)
5. 规则8.5 对于同一个对象一旦使用shared_ptr，后续就要处处使用shared_ptr (40)
6. 规则8.6 对于返回自身的shared_ptr指针的对象，要从enable_shared_from_this类派生40
7. 规则8.7 不要将使用不同版本stl、boost等模板库编译的模块连接在一起 (40)
8. 规则8.8 不要保存string::c_str()指针 (41)
9. 建议8.1 不要将stl、boost等模板库中的数据类型传递到动态链接库或者其它进程中 (41)
10. 建议8.2 使用容器时要评估大量插入删除是否会生成大量内存碎片 (41)
11. 建议8.3 使用string代替char* (41)
12. 建议8.4 使用stl、boost等知名模板库提供的容器，而不要自己实现容器 (41)
13. 建议8.5 使用新的标准库头文件 (41)
1.10 C++编程规范9 程序效率 (41)
1.10.1 9.1 C++语言特性的性能分级 (42)
1.10.2 9.2 C++语言的性能优化指导 (42)
1. 原则9.1 先测量再优化，避免不成熟的优化 (42)
2. 原则9.2 选用合适的算法和数据结构 (42)
3. 建议9.1 在构造函数中用初始化(定义时赋值)代替定义后赋值 (43)
4. 建议9.2 当心空的构造函数或析构函数的开销 (43)
5. 建议9.3 对象参数尽量传递引用(优先)或指针而不是传值 (43)
6. 建议9.4 尽量减少临时对象 (44)
7. 建议9.5 优先采用前置自增/自减 (44)
8. 建议9.6 简单访问方法尽量采用内联函数 (44)
9. 建议9.7 要审视标准库的性能规格 (44)
10. 建议9.8 用对象池重载动态内存管理器 (45)
11. 建议9.9 注意大尺寸数组的初始化效率 (45)
12. 建议9.10 避免在函数内部的小块内存分配 (45)
1.11 C++编程规范10并发 (45)
1.11.1 资料来源 (45)
1.11.2 C++编程规范10并发 (45)
1. 规则10.1 多线程、多进程并行访问共享资源时，一定要加锁保护 (45)
2. 规则10.2 锁的职责单一 (46)
3. 规则10.3 锁范围尽量小，只锁对应资源操作代码 (46)
4. 规则10.4 避免嵌套加锁；如果必须加锁，务必保证不同地方的加锁顺序是一样的 (46)
5. 建议10.1进程间通讯，使用自己保证互斥的数据库系统、共享内存，或socket消息机制；
尽量避免使用文件等进程无法管理的资源 (46)
6. 建议10.2 可重入函数尽量只使用局部变量和函数参数，少用全局变量、静态变量 (47)
7. 建议10.3 锁中避免调用函数；如果必须调用函数，务必保证不会造成死锁 (47)
8. 建议10.4 锁中避免使用跳转语句 (48)
1.12 C++编程规范11风格 (48)
1.12.1 11.1 标示符命名与定义 (48)
1. 建议11.1 类命名以大写字母开头，中间单词也以大写开头 (48)
1.12.2 11.2 排版 (48)
1. 建议11.2 类的声明按照一定的次序进行，关键字不缩进 (48)
2. 建议11.3 构造函数初始化列表在同一行或按4格缩进并排几行 (48)
1.12.3 11.3 注释 (49)
1. 建议11.4 使用‘//’注释方式，而不是‘/* */’ (49)
2. 建议11.5 为重要的类或结构体作注释，注释格式支持工具自动生成 (49)
3. 建议11.6 为所有重要的成员函数作注释 (49)
4. 建议11.7 正式发布的代码不能使用TODO 注释 (49)
1.12.4 11.4 文件组织 (49)
1. 建议11.8 整个项目需要的公共头文件应放在一个单独的目录下 (49)
2. 建议11.9 一个模块的目录层次不宜太深，以1～2层为宜，接口文件放在最外层 (49)
3. 建议11.10 保持文件前言的简洁性 (49)
1.13 12可移植性(兼容性) (49)
1.13.1 资料来源： (49)
1.13.2 12可移植性(兼容性) (49)
1.移植中一些关键问题如下： (50)
2. 建议12.1 不直接使用C++的基本数据类型，不要假定其存储尺寸长度 (50)
3. 建议12.2 避免指针截断 (50)
4. 建议12.3 注意数据类型对齐问题 (50)
5. 建议12.4 在涉及网络字节序处理时，要注意进行网络字节序与本地字节序的转换 (50)
6. 建议12.5 避免无符号数与有符号数的转换 (51)
7. 建议12.6 创建64 位常量时使用LL 或ULL 作为后缀 (51)
8. 建议12.7 区分sizeof(void *)和sizeof(int) (51)
9. 建议12.8 编译器、操作系统相关的代码独立出来 (51)
1.14 13全球化 (52)
1.14.1 13.1 多语言输入输出 (52)
1. 原则13.1 使用正确的数据类型和类处理多语言字符和字符串 (52)
2. 原则13.2 对字符进行处理时，需分配足够的内存空间并确保字符完整 (52)
3. 规则13.1 使用标准库函数判断字符属性，使应用能够支持多区域 (52)
4. 规则13.2 对字符串进行本地化排序、比较和查找时，使用有区域参数的locale::collate<>
函数 (52)
5. 建议13.1 处理Unicode数据时，注意检测BOM是否存在，避免产生多余字符或解码错误
(53)
1.14.2 13.2 单一版本 (53)
1. 规则13.3 资源与程序逻辑代码分离 (53)
2. 规则13.4 保持资源的语义完整性，不要拼接字符串资源 (53)
3. 建议13.2 资源的键名中包含该资源的应用场景信息 (54)
1.14.3 13.3 时区夏令时 (54)
1. 规则13.5 确保本地时间中时区夏令时信息完整 (54)
2. 规则13.6 避免使用本地时间直接进行时间计算 (54)
1.15 14业界编程规范和书籍 (55)
1.15.1 14.1 业界编程规范 (55)
1. 14.1.1 《google C++ code style》(google C++编程指南) (55)
2. 14.1.2 《C++编程规范101条规则、准则与最佳实践》 (55)
3. 14.1.3 Microsoft All-In-One Code Framework 《微软一站式示例代码库》 (55)
1.15.2 14.2 扩展学习材料 (56)
1. 14.2.1 C++ primer (56)
2. 14.2.2 effective C++ / more effective C++ (56)
3. 14.2.3 Effective STL (56)
4. 14.2.4 inside the C++ object model (56)
1.1 C++编程规范总则
1.1.1 资料来源
https://www.doczj.com/doc/ad4105644.html,/xiyoulele/article/details/7987123
分类：编码规范C/C++ 2012-09-17 12:49 101人阅读评论(0) 收藏举报
编程c++
C++编程规范专辑：
https://www.doczj.com/doc/ad4105644.html,/xiyoulele/article/category/1213983
1.1.2 C++编程规范总则
1. 原则：编程时必须坚持的指导思想。
2. 规则：编程时强制必须遵守的约定。
3. 建议：编程时必须加以考虑的约定。
4. 说明：对此原则/规则/建议进行必要的解释。
5. 示例：对此原则/规则/建议从好、不好两个方面给出例子。
6. 延伸阅读材料：建议进一步阅读的参考材料。
1.2 C++ 编程规范1 常量
1.2.1 资料来源
https://www.doczj.com/doc/ad4105644.html,/xiyoulele/article/details/7987126
分类：C/C++ 编码规范2012-09-17 12:50 369人阅读评论(2) 收藏举报
c++编程session编译器工作手机
1.2.2 C++ 编程规范1 常量
不变的值更易于理解、跟踪和分析，所以应该尽可能地使用常量代替变量，定义值的时候，应该把const 作为默认的选项。
1. 规则1.1 使用const常量取代宏
说明：宏是简单的文本替换，在预处理阶段时完成，运行报错时直接报相应的值；跟踪调试时也是显示值，而不是宏名；宏没有类型检查，不安全；宏没有作用域。
示例：
#define MAX_MSISDN_LEN (20) //不好的例子
const int MAX_MSISDN_LEN = 20; //好的例子
2. 规则1.2 一组相关的整型常量应定义为枚举
说明：之所以使用枚举，基于：
枚举比#define或const int更安全，因为编译器会检查参数值是否位于枚举取值范围内，从而避免错误发生。
示例：
//好的例子：
enum DayOfWeek{sunday,monday, tuesday, wednesday, thursday, friday, saturday};
enum Color{black, blue, white, red, purple};
BOOL ColorizeCalendar(DayOfWeek today, Color todaysColor);
ColorizeCalendar(blue, sunday); //编译报错，Blue和Sunday位置错误
//不好的例子:
const int sunday = 0;
const int monday = 1;
const int black = 0;
const int blue = 1;
BOOL ColorizeCalendar(int today, int todaysColor);
ColorizeCalendar(blue, sunday); //不会报错
当枚举值需要对应到具体数值时，须在声明时显示赋值。否则不需要显式赋值，以避免重复赋值，降低维护(增加、删除成员)工作量。
示例：
//好的例子：S协议里定义的设备ID值，用于标识设备类型
enum TDeviceType
{
DEV_UNKNOWN = -1,
DEV_DSMP = 0,
DEV_ISMG = 1,
DEV_WAPPORTAL = 2
};
程序内部使用，仅用于分类的情况，不应该进行显式的赋值。
示例：
//好的例子：程序中用来标识会话状态的枚举定义
enum TSessionState
{
SESSION_STATE_INIT,
SESSION_STATE_CLOSED,
SESSION_STATE_WAITING_FOR_RSP
};
应当尽量避免枚举值重复，如必须重复也要用已定义的枚举来修饰，例如：
typedef enum
{
RTCP_SR = 200,
RTCP_MIN_TYPE = RTCP_SR, //must be lowest known type
RTCP_RR = 201,
RTCP_SDES = 202,
RTCP_BYE = 203,
RTCP_APP = 204,
RTCP_RTPFB = 205,
RTCP_PSFB = 206,
RTCP_XR = 207,
RTCP_RSI = 208,
RTCP_PUBPORTS = 209,
RTCP_MAX_TYPE = RTCP_PUBPORTS //must be highest known type
} rtcp_type_t;
3. 规则1.3 不相关的常量，即使取值一样，也必须分别定义
说明：一个常量只用来表示一个特定功能，即一个常量不能有多种用途。
示例：
//好的例子：协议A和协议B，手机号(MSISDN)的长度都是20。
unsigned const int A_MAX_MSISDN_LEN = 20;
unsigned const int B_MAX_MSISDN_LEN = 20;
//或者使用不同的名字空间：
namespace alib
{
unsigned const int MAX_MSISDN_LEN = 20;
}
namespace blib
{
unsigned const int MAX_MSISDN_LEN = 20;
}
4. 建议1.1 尽可能使用const
说明：在声明的变量或参数前加上关键字const用于指明变量值不可被篡改。类成员函数加上const 限定符表明该函数不会修改类成员变量的状态。
使用const常见的场景：
A. 函数参数：传递引用时，如果函数不会修改传入参数, 该形参应声明为const。
B. 成员函数：访问函数(如get函数)；不修改任何数据成员的函数；未调用非const函数、未返回数据
成员的非const指针或引用的函数。
C. 数据成员：如果数据成员在对象构造之后不再发生变化, 可将其定义为const。
1.3 C++编程规范2 初始化和类型转换
资料来源：
https://www.doczj.com/doc/ad4105644.html,/xiyoulele/article/details/7987132
分类：C/C++ 编码规范2012-09-17 12:52 471人阅读评论(0) 收藏举报
编程c++编译器classstringemail
1.3.1
2.1 声明、定义与初始化
1. 规则
2.1 禁止用memcpy、memset初始化非POD对象
说明：POD 全称是“Plain Old Data”，是C++ 98标准(ISO/IEC 14882, first edition, 1998-09-01)中引入的一个概念，POD类型主要包括int, char, float，double，enumeration，void，指针等原始类型及其集合类型，不能使用封装和面对对象特性（如用户定义的构造/赋值/析构函数、基类、虚函数等）。
由于非POD类型比如非集合类型的class对象，可能存在虚函数，内存布局不确定，跟编译器有关，滥用内存拷贝可能会导致严重的问题。
即使对集合类型的class，使用直接的内存拷贝和比较，破坏了信息隐蔽和数据保护的作用，也不提倡memcpy、memset操作。
示例：×××产品程序异常退出(core dump)。
经过现场环境的模似，程序产生COREDUMP，其原因是：在初始化函数内使用memset(this, 0,sizeof(*this))进行了类的初始化，将类的虚函数表指针被清空，从而导致使用空指针。
解决方案：使用C++构造函数初始化，不要使用memset函数初始化类对象。
2. 建议2.1 变量使用时才声明并初始化
说明：变量在使用前未赋初值，是常见的低级编程错误。使用前才声明变量并同时初始化，非常方便地避免了此类低级错误。
在函数开始位置声明所有变量，后面才使用变量，作用域覆盖整个函数实现，容易导致如下问题：程序难以理解和维护：变量的定义与使用分离。
变量难以合理初始化：在函数开始时，经常没有足够的信息进行变量初始化，往往用某个默认的空值(比如零)来初始化，这通常是一种浪费，如果变量在被赋于有效值以前使用，还会导致错误。
遵循变量作用域最小化原则与就近声明原则，使得代码更容易阅读,方便了解变量的类型和初始值。
特别是，应使用初始化的方式替代声明再赋值。
示例：
//不好的例子：声明与初始化分离
string name; //声明时未初始化：调用缺省构造函数
//…….
name=”zhangsan”; //再次调用赋值操作符函数；声明与定义在不同的地方，理解相对困难
//好的例子：声明与初始化一体，理解相对容易
string name(”zhangsan”); //调用一次构造函数
3. 建议2.2 避免构造函数做复杂的初始化，可以使用“init”函数
说明：正如函数的变量都在函数内部初始化一样，类数据成员最好的初始化场所就是构造函数，数据成员都应该尽量在构造函数中初始化。
以下情况可以使用init()函数来初始化：
需要提供初始化返回信息。
数据成员初始化可能抛异常。
数据成员初始化失败会造成该类对象初始化失败，引起不确定状态。
数据成员初始化依赖this指针：构造函数没结束，对象就没有构造出来，构造函数内不能使用this成员；
数据成员初始化需要调用虚函数。在构造函数和析构函数中调用虚函数，会导致未定义的行为。
示例：数据成员初始化可能抛异常：
class CPPRule
{
public:
CPPRule():size_(0), res (null) {}; //仅进行值初始化
long init(int size)
{
//根据传入的参数初始化size_, 分配资源res
}
private:
int size_;
ResourcePtr* res;
};
//使用方法：
CPPRule a;
a.init(100);
4. 建议2.3 初始化列表要严格按照成员声明顺序来初始化它们
说明：编译器会按照数据成员在类定义中声明的顺序进行初始化，而不是按照初始化列表中的顺序，如果打乱初始化列表的顺序实际上不起作用，但会造成阅读和理解上的混淆；特别是成员变量之间存在依赖关系时可能导致BUG。
示例：
//不好的例子：初始化顺序与声明顺序不一致
class Employee
{
public:
Employee(const char* firstName, const char* lastName)
: firstName_(firstName), lastName_(lastName), email_(firstName_ + "." + lastName_ + "@https://www.doczj.com/doc/ad4105644.html,")
{};
private:
string email_, firstName_, lastName_;
};
类定义email_是在firstName_, lastName_之前声明，它将首先初始化，但使用了未初始化的firstName_和lastName_，导致错误。
在成员声明时，应按照成员相互依赖关系按顺序声明。
5. 建议2.4 明确有外部依赖关系的全局与静态对象的初始化顺序
说明：如果全局对象A的成员变量有外部依赖，比如依赖另外一个全局变量B，在A的构造函数中访问B，隐含的规则就是B先于A初始化，然而全局与静态对象的初始化与析构顺序未有严格定义，无法确保B已经完成初始化，而每次生成可执行程序都可能发生变化，这类BUG难以定位。
通常采用单件(Singleton)模式或者把有依赖关系的全局对象放在一个文件中定义来明确初始化顺序。
同一个文件中，若全局对象a在全局对象b之前定义，则a一定会在b之前初始化；但是不同文件中的全局对象就没有固定的初始化顺序。可以在main()或pthread_once() 内初始化一个运行期间不回收的指针。
1.3.2
2.2 类型转换
避免使用类型分支来定制行为：类型分支来定制行为容易出错，是企图用C++编写C代码的明显标志。
这是一种很不灵活的技术，要添加新类型时，如果忘记修改所有分支，编译器也不会告知。使用模板和虚函数，让类型自己而不是调用它们的代码来决定行为。
1. 规则
2.2 使用C++风格的类型转换，不要使用C风格的类型转换
说明：C++的类型转换由于采用关键字，更醒目，更容易查找，编程中强迫程序员多停留思考片刻，谨慎使用强制转换。
C++使用const_cast, dynamic_cast, static_cast, reinterpret_cast等新的类型转换，它们允许用户选择适当级别的转换符，而不是像C那样全用一个转换符。
dynamic_cast：主要用于下行转换，dynamic_cast具有类型检查的功能。dynamic_cast有一定的开销，建议在调测代码中使用。
static_cast：和C风格转换相似可做值的强制转换，或上行转换(把派生类的指针或引用转换成基类的指针或引用)。该转换经常用于消除多重继承带来的类型歧义，是相对安全的。下行转换(把基类的指针或引用转换成派生类的指针或引用)时，由于没有动态类型检查，所以不安全的，不提倡下行转换。
reinterpret_cast：用于转换不相关的类型。reinterpret_cast强制编译器将某个类型对象的内存重新解释成另一种类型，相关代码可移植不好。建议对reinterpret_cast<> 的用法进行注释，有助于减少维护者在看到这种转换时的顾虑。
const_cast：用于移除对象的const属性，使对象变得可修改。
示例：
extern void Fun(DerivedClass* pd);
void Gun(BaseClass* pb)
{
//不好的例子: C风格强制转换，转换会导致对象布局不一致，编译不报错，运行时可能会崩溃
DerivedClass* pd = (DerivedClass *)pb;
//好的例子: C++风格强制转换，明确知道pb实际指向DerivedClass
DerivedClass* pd = dynamic_cast< DerivedClass *>(pb);
if(pd)
Fun(pd);
}
2. 建议2.5 避免使用reinterpret_cast
说明：reinterpret_cast用于转换不相关类型。尝试用reinterpret_cast将一种类型强制转换另一种类型，这破坏了类型的安全性与可靠性，是一种不安全的转换。不同类型之间尽量避免转换。
3. 建议2.6 避免使用const_cast
说明：const_cast用于移除对象的const性质。
const属性提供一种安全感，让程序员知道这个定义是固定不变的，从而不需要担心后面的变化。如果const属性在程序员不知道的地方被消除，会带来很多严重的后果。
示例：不好的例子
unsigned const int arraySize = 1024;
int &newArraySize = const_cast
newArraySize = 2048;
这里如果不通过引用或者指针访问arraySize，那么arraySize的值始终是1024。可是如果被作为一个指针或者引用传给其他函数进行取值的话，会发现值变成了2048。
示例：不好的例子：强制去掉入参的const属性，导致函数可以对入参进行修改。
void setObj(TBase const *obj)
{
//m_pObj的定义为:
TBase *m_pObj;
m_pObj = const_cast
m_pObj->value = 123;
}
4. 建议2.7 使用虚函数替换dynamic_cast
说明：很多刚从C语言转过了的程序员习惯这样的思路：若对象的类型是T1，则做某种处理；若对象的类型是T2，则做另外的处理等等。但C++提供了更好的解决方案：虚函数。
虚函数与dynamic_cast类型转换相比：
A. 虚函数更安全，不会出现强制转换错的情况；
B. 虚函数效率更高：用函数指针，避免条件判断；
C. 虚函数不需要在编码时确定对象的真实类型，而dynamic_cast必须告知要转成的类型，运行时若类
型不当返回空指针或者抛异常；
D. 虚函数适用性更强：虚函数是真正动态绑定；类型转换当增加或删除一个派生类时，dynamic_cast
必须增减相应的代码。
1.4 C++编程规范3 函数
资料来源：
https://www.doczj.com/doc/ad4105644.html,/xiyoulele/article/details/7987137
分类：C/C++ 编码规范2012-09-17 12:53 219人阅读评论(0) 收藏举报
c++编程编译器classinclude扩展
1.4.1 3.1 内联函数
1. 规则3.1 内联函数(inline function)小于10行
说明：内联函数具有一般函数的特性，它与一般函数不同之处只在于函数调用的处理。一般函数进行调用时，要将程序执行权转到被调用函数中，然后再返回到调用它的函数中；而内联函数在调用时，是将调用表达式用内联函数体来替换。
内联函数只适合于只有1～10行的小函数。对一个含有许多语句的大函数，函数调用和返回的开销相对来说微不足道，也没有必要用内联函数实现，一般的编译器会放弃内联方式，而采用普通的方式调用函数。
如果内联函数包含复杂的控制结构，如循环、分支(switch)、try-catch等语句，一般编译器将该函数视同普通函数。虚函数、递归函数不能被用来做内联函数。
2. 规则
3.2 使用内联函数代替函数宏
说明：C++中也支持宏的功能，但是宏有其自身固有的缺陷(例如无法对参数进行类型检查)，因此，能使用内联函数的地方，一定不使用宏。
示例：
//较好的例子:
template
{
return (x>y)?x:y;
}
//不好的例子:
#define MAX(x,y) ((x)>(y)?(x):(y))
例外：一些通用且成熟的应用，如：对new, delete的封装处理，可以保留对宏的使用。
3. 建议3.1 内联函数应该放在头文件中声明，而且在函数前添加inline关键字
说明：内联函数的定义对编译器而言必须可见，以便在调用点将函数展开。放在头文件中可以保证对编译器可见，修改或者删除内联函数时，重新编译使用该头文件的所有源文件。
4. 建议3.2 内联函数的实现放在独立的文件
说明：确保接口清晰。如果使用者和维护者看见声明包含大量的内联实现，会干扰他们的思维，降低声明的可读性和可维护性。所以除了最简单的成员存取函数外，其他较为复杂内联函数的实现放到独立的头文件中(建议使用.inl为扩展名)，在声明头文件的最后include。
//cpp_rule.h
#ifndef CPP_RULE_H
#define CPP_RULE_H
class CppRule
{
public:
inline inlineFunction();
};
#include “cpp_rule.inl”
#endif //CPP_RULE_H
//cpp_rule.inl
#ifndef CPP_RULE_INL
#define CPP_RULE_INL
inline CppRule::inlineFunction()
{
//内联函数实现
}
#endif //CPP_RULE_INL
1.4.2 3.2 函数参数
1. 建议3.3 入参尽量用const引用取代指针
说明：引用比指针更安全，因为它一定非空，且一定不会再指向其他目标；引用不需要检查非法的NULL指针。
如果是基于老平台开发的产品，则优先顺从原有平台的处理方式。
选择const避免参数被修改，让代码阅读者清晰地知道该参数不被修改，可大大增强代码可读性。
2. 建议
3.4 消除未使用函数参数
说明：检查未使用的函数参数，确认是否需要使用该函数参数，如果不需要直接删除参数名。
当实现接口时，有一些参数没有被引用是相当常见的。编译器会发现未使用的参数，并产生一个警告，有些组件甚至会认为这是一个错误。为避免发生如此情况，将未使用的参数使用/* 参数名*/ 语法将其注释掉。
示例：
//好的例子:将localityHint参数名去掉，在注释中保留参数名以备参考和理解参数含义
pointer allocate(size_type numObjects, const void * /* localityHint */ = 0)
{
return static_cast
}
3. 建议3.5 尽量少用缺省参数
说明：使用参数的缺省值仅仅方便函数的使用，没有赋予函数新的功能，但降低函数的可理解。
缺省参数使得拷贝粘贴以前函数调用的代码难以呈现所有参数，当缺省参数不适用于新代码时可能导致重大问题。
1.4.3 3.3 函数指针
1. 建议3.6 尽量少用函数指针
说明：不少代码中还是用函数指针来实现一些功能扩展（如封装），但函数指针难以理解和难以维护，建议使用C++中派生与继承的基本用法，少用函数指针。
1.5 C++编程规范4 类
资料来源：
https://www.doczj.com/doc/ad4105644.html,/xiyoulele/article/details/7987140
分类：C/C++ 编码规范2012-09-17 12:54 246人阅读评论(0) 收藏举报
编程c++stringclassdeleteinheritance
1.5.1 4.1 类的设计
类是面向对象设计的基础，一个好的类应该职责单一，接口清晰、少而完备，类间低耦合、类内高内聚，并且很好地展现封装、继承、多态、模块化等特性。
1. 原则4.1 类职责单一
说明：类应该职责单一。如果一个类的职责过多，往往难以设计、实现、使用、维护。
随着功能的扩展，类的职责范围自然也扩大，但职责不应该发散。
用小类代替巨类。小类更易于编写，测试，使用和维护。用小类体现简单设计的概念；巨类会削弱封装性，巨类往往承担过多职责，试图提供“完整”的解决方案，但往往难以真正成功。
如果一个类有10个以上数据成员，类的职责可能过多。
2. 原则4.2 隐藏信息
说明：封装是面向对象设计和编程的核心概念之一。隐藏实现的内部数据，减少调用者代码与具体实现代码之间的依赖。
A. 尽量减少全局和共享数据；
B. 禁止成员函数返回成员可写的引用或者指针；
C. 将数据成员设为私有的(struct除外)，并提供相关存取函数；
D. 避免为每个类数据成员提供访问函数；
E. 运行时多态，将内部实现(派生类提供)与对外接口(基类提供)分离。
3. 原则
4.3 尽量使类的接口正交、少而完备
说明：应该围绕一个核心去定义接口、提供服务、与其他类合作，从而易于实现、理解、使用、测试和维护。接口函数功能正交，尽量避免一个接口功能覆盖另一个接口功能。接口函数太多，会难以理解、使用和维护。如果一个类包含20个以上的非私有成员函数，类的接口可能不够精简。
4. 规则4.1 模块间对外接口类不要暴露私有和保护成员
说明：对外接口类暴露受保护或者私有成员则破坏了封装，一旦因为类的设计变更(增加，删除，修改内部成员)会导致关联组件或系统的代码重新编译，从而增加系统编译时间，也产生了二进制兼容问题，导致关联升级和打补丁。所以除非必要，不要在接口类中暴露私有和保护成员。
有如下几种做法：
(1). 使用纯虚类作为接口类，用实现类完成实现，使用者只看到接口类，这种做法缺点是：
A. 代码结构相对复杂。
B. 新增接口必须放在原有接口后面，不能改变原有接口的顺序。否则，因为虚函数表的原因，会导致
客户代码重新编译。
(2). 接口类使用PIMPL模式(只有一个指向实现类指针的私有数据成员)，所有私有成员都封装在实现类中(实现类可以不暴露为头文件，直接放在实现文件中)。(Pimpl机制是Private Implementation的缩写)
A. 代码结构简单，容易理解。
B. 可以节省虚函数开销，但是有间接访问开销。
C. 修改实现不会导致客户代码重新编译。
class Interface
{
public:
void function();
private:
Implementation* impl_;
};
class Implementation
{
public:
int i;
int j;
};
void Interface:: function ()
{
++impl_->i;
}
5. 规则4.2 避免成员函数返回成员可写的引用或者指针
说明：破坏了类的封装性，对象本身不知道的情况下对象的成员被修改。
示例：不好的例子
class Alarm
{
public:
string& getname(){return name;} //破坏类的封装性，成员name被暴露
private:
string name;
};
例外：某些情况下确实需要返回可写引用或者指针的，例如单件模式的一种写法：Type& Type::Instance()
{
static Type instance;
return instance;
}
6. 规则4.3 禁止类之间循环依赖
说明：循环依赖会导致系统耦合度大大增加，所以类之间禁止循环依赖。类A依赖类B，类B依赖类A。
出现这种情况需要对类设计进行调整，引入类C：
升级：将关联业务提到类C，使类C依赖类A和类B，来消除循环依赖
降级：将关联业务提到类C，使类A和类B都依赖类C，来消除循环依赖。
示例：类Rectangle和类Window互相依赖
class Rectangle
{
public:
Rectangle(int x1, int y1, int x2, int y2);
Rectangle(const Window& w);
};
class Window
{
public:
Window(int xCenter, int yCenter, int width, int height);
Window(const Rectangle& r);
};
可以增加类BoxUtil做为转换，不用产生相互依赖
class BoxUtil
{
public:
static Rectangle toRectangle(const Window& w);
static Window toWindow(const Rectangle& r);
};
7. 建议4.1 将数据成员设为私有的(struct除外)，并提供相关存取函数
说明：信息隐藏是良好设计的关键，应该将所有数据成员设为私有，精确的控制成员变量的读写，对外屏蔽内部实现。否则意味类的部分状态可能无法控制、无法预测，原因是：
A. 非private成员破坏了类的封装性，导致类本身不知道其数据成员何时被修改；
B. 任何对类的修改都会延伸影响到使用该类的代码。
将数据成员私有化，必要时提供相关存取函数，如定义变量foo_及取值函数foo()、赋值操作符set_foo()。存取函数一般内联在头文件中定义成内联函数。如果外部没有需求，私有数据成员可以不提供存取函数，以达到隐藏和保护的目的。不要通过存取函数来访问私有数据成员的地址(见规则4.2)。
8. 建议4.2 使用PIMPL模式，确保私有成员真正不可见
说明：C++将私有成员成员指定为不可访问，但还是可见的，可以通过PIMPL惯用法使私有成员在当前类的范围中不可见。PIMPL主要是通过前置声明，达到接口与实现的分离的效果，降低编译时间，降低耦合。
示例：
class Map
{
private:
struct Impl;
shared_ptr
};
1.5.2 4.2 构造、赋值和析构
1. 规则4.4 包含成员变量的类，须定义构造函数或者默认构造函数
说明：如果类有成员变量，没有定义构造函数，又没有定义默认构造函数，编译器将自动生成一个构造函数，但编译器生成的构造函数并不会对成员变量进行初始化，对象状态处于一种不确定性。
例外：如果这个类是从另一个类继承下来，且没有增加成员变量，则不用提供默认构造函数
示例：如下代码没有构造函数，私有数据成员无法初始化：
class CMessage
{
public:
void ProcessOutMsg()
{
//…
}
private:
unsigned int msgid;
unsigned int msglen;
unsigned char *msgbuffer;
};
CMessage msg; //msg成员变量没有初始化
msg.ProcessOutMsg(); //后续使用存在隐患
//因此，有必要定义默认构造函数，如下：
class CMessage
{
public:
CMessage ():
msgid(0),
msglen (0),
msgbuffer (NULL)
{
}
//...
};
2. 规则4.5 为避免隐式转换，将单参数构造函数声明为explicit
说明：单参数构造函数如果没有用explict(adj. 明确的；清楚的；直率的；详述的)声明，则会成为隐式转换函数。
示例：
class Foo
{
public:
explicit Foo(const string &name):m_name(name)
{
}
private:
string m_name;
};
ProcessFoo("zhangsan"); //函数调用时，编译器报错，因为显式禁止隐式转换
定义了Foo::Foo(string &name)，当形参是Foo对象实参为字符串时，构造函数Foo::Foo(string &name)被调用并将该字符串转换成一个Foo临时对象传给调用函数，可能导致非预期的隐式转换。解决办法：在构造函数前加上explicit限制隐式转换。
3. 规则
4.6 包含资源管理的类应自定义拷贝构造函数、赋值操作符和析构函数
说明：如果用户不定义，编译器默认会生成拷贝构造函数、赋值操作符和析构函数。自动生成的拷贝构造函数、赋值操作符只是将所有源对象的成员简单赋值给目的对象，即浅拷贝(shallow copy)；自动生成析构函数是空的。这对于包含资源管理的类来说是不够的：比如从堆中申请的资源，浅拷贝会使得源对象和目的对象的成员指向同一内存，会导致资源重复释放。空的析构函数不会释放已申请内存。
如果不需要拷贝构造函数和赋值操作符，可以声明为private属性，让它们失效。
示例：如果结构或对象中包含指针，定义自己的拷贝构造函数和赋值操作符以避免野指针。
class GIDArr
{
public:
GIDArr()
{
iNum = 0;
pGid = NULL;
}
~GIDArr()
{
if (pGid)
{
delete [] pGid;
}
}
private:
int iNum;
char *pGid;
GIDArr(const GIDArr& rhs);
GIDArr& operator = (const GIDArr& rhs) ;
}GIDArr;
4. 规则4.7 让operator=返回*this的引用
说明：符合连续赋值的常见用法和习惯。
示例：
String& String::operator=(const String& rhs)
{
//...
return *this; //返回左边的对象
}
string w, x, y, z;
w = x = y = z = "Hello";
5. 规则4.8 在operator=中检查给自己赋值的情况
说明：自己给自己赋值和普通赋值有很多不同，若不防范会出问题。示例：
class String
{
public:
String(const char *value);
~String();
String& operator=(const String& rhs);
private:
char *data;
};
//自赋值，合法
String a;
a=a;
//不好的例子：忽略了给自己赋值的情况，导致访问野指针
String& String::operator=(const String& rhs)
{
delete [] data; //删除data
//分配新内存，将rhs的值拷贝给它
data = new char[strlen(rhs.data) + 1]; //rhs.data已经删除，变成野指针
strcpy(data, rhs.data);
return *this;
}
//好的例子：检查给自己赋值的情况
String& String::operator=(const String& rhs)
{
if(this != &rhs)
{
delete [] data;
data = new char[strlen(rhs.data) + 1];
strcpy(data, rhs.data);
}
return *this;
}
6. 规则4.9 在拷贝构造函数、赋值操作符中对所有数据成员赋值
说明：确保构造函数、赋值操作符的对象完整性，避免初始化不完全。
7. 规则4.10 通过基类指针来执行删除操作时，基类的析构函数设为公有且虚拟的说明：只有基类析构函数是虚拟的，才能保证派生类的析构函数被调用。
示例：基类定义中无虚析构函数导致的内存泄漏。
//如下平台定义了基类A，完成获取版本号的功能。
class A
{
public:
virtual std::string getVersion()=0;
};
//产品派生类B，实现其具体功能，其定义如下：
class B:public A
{
public:
B()
{
cout<<"B()"< m_int = new int [100]; } ~B() { cout<<"~B()"< delete [] m_int; } std::string getVersion(){ return std::string("hello!");} private: int *m_int; }; //模拟该接口的调用代码如下： int main(int argc, char* args[]) { A *p = new B(); delete p; return 0; } 派生类B虽然在析构函数中进行了资源清理，但不幸的是该派生类析构函数永远不会被调用。由于基类A没有定义析构函数，更没有定义虚析构函数，当对象被销毁时，只会调用系统默认的析构函数，故导致内存泄漏。 8. 规则4.11 避免在构造函数和析构函数中调用虚函数 说明：在构造函数和析构函数中调用虚函数，会导致未定义的行为。 在C++中，一个基类一次只构造一个完整的对象。 示例：类BaseA是基类，DeriveB是派生类 class BaseA //基类BaseA { public: BaseA(); virtual void log() const=0; //不同的派生类调用不同的日志文件 }; BaseA::BaseA() //基类构造函数 { log(); //调用虚函数log } class DeriveB:public BaseA //派生类 { public: virtual void log() const; }; 当执行如下语句： DeriveB B; 会先执行DeriveB的构造函数，但首先调用BaseA的构造函数，由于BaseA的构造函数调用虚函数log，此时log还是基类的版本，只有基类构造完成后，才会完成派生类的构造，从而导致未定义的行为。 同样的道理也适用于析构函数。 9. 建议4.3 拷贝构造函数和赋值操作符的参数定义成const引用类型 说明：拷贝构造函数和赋值操作符不可以改变它所引用的对象。 10. 建议4.4 在析构函数中集中释放资源 说明：使用析构函数来集中处理资源清理工作。如果在析构函数之前，资源被释放（如release函数），请将资源设置为NULL，以保证析构函数不会重复释放。 1.5.3 4.3 继承 华为软件编程规范Revised on November 25, 2020 目录 1 排版 6 2 注释11 3 标识符命名18 4 可读性20 5 变量、结构22 6 函数、过程28 7 可测性36 8 程序效率40 9 质量保证44 10 代码编辑、编译、审查50 11 代码测试、维护52 12 宏53 1 排版 11-1：程序块要采用缩进风格编写，缩进的空格数为4个。 说明：对于由开发工具自动生成的代码可以有不一致。 11-2：相对独立的程序块之间、变量说明之后必须加空行。 示例：如下例子不符合规范。 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 应如下书写 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 11-3：较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。 示例： + STAT_SIZE_PER_FRAM * sizeof( _UL ); act_task_table[frame_id * STAT_TASK_CHECK_NUMBER + index].occupied = stat_poi[index].occupied; act_task_table[taskno].duration_true_or_false = SYS_get_sccp_statistic_state( stat_item ); report_or_not_flag = ((taskno < MAX_ACT_TASK_NUMBER) && (n7stat_stat_item_valid (stat_item)) && (act_task_table[taskno].result_data != 0)); 1 Java 编程规范 1.1 排版 1.1.1 规则 规则1程序块要采用缩进风格编写，缩进的空格数为4个，不允许使用TAB缩进。(1.42+) 说明：缩进使程序更易阅读，使用空格缩进可以适应不同操作系统与不同开发工具。 规则2分界符（如大括号…{?和…}?）应各独占一行，同时与引用它们的语句左对齐。在函数体的开始、类和接口的定义、以及if、for、do、while、switch、case语句中的程序 或者static、,synchronized等语句块中都要采用如上的缩进方式。(1.42+) 示例: if (a>b) { doStart(); } 规则3较长的语句、表达式或参数（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐， 语句可读。(1.42+) 示例： if (logger.isDebugEnabled()) { logger.debug("Session destroyed,call-id" + event.getSession().getCallId()); } 规则4不允许把多个短语句写在一行中，即一行只写一条语句(1.42+) 说明：阅读代码更加清晰 示例：如下例子不符合规范。 Object o = new Object(); Object b = null; 规则5if, for, do, while, case, switch, default 等语句自占一行，且if, for, do, while,switch等语句的执行语句无论多少都要加括号{},case 的执行语句中如果定义变量必须加括号{}。 (1.42+) 说明：阅读代码更加清晰，减少错误产生 示例： if (a>b) { doStart(); } Java语言编码规范 Prepared by 拟制Date 日期 yyyy-mm-dd Reviewed by 评审人Date 日期 yyyy-mm-dd Approved by 批准Date 日期 yyyy-mm-dd Revision Record 修订记录 Table of Contents 目录 1. 范围 (4) 2. 规范性引用文件 (4) 3. 术语和定义 (4) 4. 排版规范 (5) 4.1. 规则 (5) 4.2. 建议 (7) 5. 注释规范 (9) 5.1. 规则 (9) 5.2. 建议 (15) 6. 命名规范 (17) 6.1. 规则 (17) 6.2. 建议 (18) 7. 编码规范 (20) 7.1. 规则 (20) 7.2. 建议 (24) 8. JTEST规范 (26) 8.1. 规则 (26) 8.2. 建议 (27) 1.范围 本规范规定了使用Java语言编程时排版、注释、命名、编码和JTEST的规则和建议。 本规范适用于使用Java语言编程的产品和项目。 2.规范性引用文件 下列文件中的条款通过本规范的引用而成为本规范的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本规范，然而，鼓励根据本规范达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本规范。 3.术语和定义 规则：编程时强制必须遵守的原则。 建议：编程时必须加以考虑的原则。 格式：对此规范格式的说明。 说明：对此规范或建议进行必要的解释。 示例：对此规范或建议从正、反两个方面给出例子。 文档编号产品版本受控状态 DC-SB-2003-1005V 1.0 内部 产品名称：软件编程规范共页 软件编程规范 (仅供内部使用) 北京世纪百合科技有限公司 Beijing Centurial Lily Technology Co.,Ltd. 版权所有不得复制 文档修改记录 目录 1.引言 (4) 1.1 目的 (4) 1.2 范围 (4) 2.规范 (4) 2.1 文件 (4) 2.2版面风格 (8) 2.3 标识符命名 (12) 2.4 函数与宏 (14) 2.5 代码的可靠性 (18) 3.附录：通用类型的公共定义 (23) 1.引言 1.1目的 本规范的目的在于增加源代码的可读性，减少程序员对代码理解上的偏差，使程序员能够编写出可靠的代码，降低代码维护成本。 1.2范围 本规范内容涉及范围包括：文件、版面、注释、标识符、变量和结构、函数、宏以及可理解性等。本规范适用于公司开发的所有软件产品。在新软件的编码过程中本规范必须执行。 2.规范 2.1文件 2.1.1头文件的名称一律为小写，格式为“子系统名_文件名.h”。例如： ipf_protocol.h等。 2.1.2头文件的格式如下： ?注释头，格式参见软件编程规范； ?头文件预编译开关开始，格式为： #ifndef 预编译开关 #define 预编译开关 其中预编译开关格式为：“ _文件名_H”，其中文件名一律大写 ?头文件内容； ?头文件预编译开关结束，格式为： #endif 用来和头文件预编译开关的开始对应。 例如：以下为ipf_ip.h头文件的内容： /************************************************************ Copyright (c) Lily Of The Century Technology Co., LTD. ALL RIGHTS RESERVED Description: // 用于详细说明此程序文件完成的主要功能 *************************************************************/ #ifndef _IPF_IP_H #define _IPF_IP_H ... 华为公司招聘条件要求 软件研发工程师: 工作职责 : 负责通信系统软件模块的设计、编码、调试、测试等工作，参与相关质量活动，确保设计、实现、测试工作按时保质完成 职位要求: 1、计算机、通信或相关专业本科以上学历 2、熟悉C/C++、JAVA底层驱动软件编程，熟悉 TCP/IP 协议、 Internet 网的基本知识 3 、对通信知识有一定基础 4、能够熟练阅读和理解英文资料 2、硬件研发工程师 : 工作职责 : 从事单板硬件、光技术、逻辑、射频、装备、 机电、CAD器件可靠性等模块开发工作，参与相关质量活动, 确 保设计、实现、测试工作的按时保质完成。 职位要求: 1、电子、计算机、通信、自控、自动化相关专业本科以上学历 2、具备良好的数字、模拟电路基础 3、熟悉C/嵌入式系统开发/底层驱动软件编程/逻辑设计 4、能 够熟练阅读和理解英文资料芯片设计工程师: 工作职责 : 1、负责数字 / 模拟芯片开发和设计、验证、实现工作； 2、按照模块规格和芯片总体方案的要求，严格遵循开发流程、模板、标准和规范，承担 模块的详细设计和实施工作，确保开发工作按时按质完成； 3、及时编写各种设计文档和标准化资料，实现资源、经验共享。 职位要求: 1、微电子、计算机、通信工程等相关专业 2、了解或实际应用过 VHDL/Verilog 语言编程，掌握数字电路设计，或具有FPGA设计经验，或熟悉综合（SYN”时序分析（STA /布局布线（Place and routing ） /可测性设计（DFT，有相关工具应用的经验；或具有模拟 IC 设计项目经验 射频开发工程师: 工作职责 : 负责通讯设备射频模块的开发、设计和优化工作；从事无线基站通信设备天馈及其解决方案方面的研究和开发工作。 职位要求: 1、电子、通信、电磁场与微波、微电子半导体等专业本科及以上学历； 2、能够熟练阅读和理解英文资料； 3、掌握并有RF仿真经验（如ADS优先； 4、有射频产品开发经验优先。 云计算研发工程师: 代码规范文档 目录 1 概述 (5) 1.1 编写目的 (5) 1.2 文档约定 (5) 1.3 预期的读者和阅读建议 (5) 1.4 参考文献 (5) 2 排版要求 (5) 2.1 程序块缩进 (5) 2.2 程序块之间空行 (5) 2.3 长语句和长表达式 (6) 2.4 循环、判断等长表达式或语句 (7) 2.5 长参数 (7) 2.6 短语句 (8) 2.7 条件、循环语句 (8) 2.8 语句对齐 (8) 2.9 函数、过程和结构等语句块 (9) 2.10 程序块分界符 (9) 2.11 操作符前后空格 (10) 2.12 其他 (11) 3 注释 (11) 3.1 有效注释量 (11) 3.2 公司标识 (11) 3.3 说明性文件 (12) 3.4 源文件头 (13) 3.5 函数头部说明 (13) 3.6 注释与代码一致 (14) 3.7 注释内容 (14) 3.8 注释缩写 (14) 3.9 注释位置 (14) 3.10 变量、常量注释 (15) 3.11 数据结构的注释 (15) 3.12 全局变量 (16) 3.13 注释缩排 (16) 3.14 注释与代码之间空行 (17) 3.15 变量定义、分支语句 (17) 3.16 其他 (19) 4 标识符命名 (20) 4.1 命名清晰 (20) 4.2 特殊命名需注释 (21) 4.3 命名风格保持一致 (21) 4.4 变量命名 (21) 4.5 命名规范与系统风格一致 (21) 4.6 其他 (22) 5 可读性 (23) 5.1 运算符优先级 (23) 5.2 避免直接使用数字作为标识符 (23) 5.3 其他 (24) 6 变量、结构 (25) 6.1 公共变量 (25) 6.2 公共变量说明 (25) 6.3 公共变量访问说明 (25) 6.4 公共变量赋值 (26) 6.5 防止局部变量与公共变量同名。 (26) 6.6 严禁使用未经初始化的变量作为右值。 (26) 6.7 其他 (26) 7 函数、过程 (34) 7.1 对所调用函数的错误返回码要仔细、全面地处理。 (34) 7.2 明确函数功能，精确（而不是近似）地实现函数设计。 (34) 7.3 局部变量 (34) 7.4 全局变量 (34) 7.5 接口函数参数 (35) 7.6 其他 (35) 8 可测性 (44) 8.1 调测开关 (44) 8.2 打印信息 (45) 8.3 单元测试 (45) 8.4 集成测试 (45) 8.5 断言使用 (45) 8.6 设置与取消有关测试手段时，不能影响软件功能功能 (48) 8.7 版本维护 (48) 8.8 其他 (48) 9 程序效率 (50) 9.1 编程时要经常注意代码的效率。 (50) 9.2 提高代码效率 (50) 9.3 全局效率高于局部效率 (51) 9.4 提高代码空间效率 (51) 9.5 循环体内工作量最小化 (52) 9.6 其他 (53) 10 质量保证 (56) 10.1 在软件设计过程中构筑软件质量。 (56) 10.2 代码质量保证优先原则 (56) 10.3 只引用属于自己的存贮空间。 (56) 10.4 防止引用已经释放的内存空间。 (56) 10.5 内存及时释放 (57) 10.6 文件句柄及时关闭 (57) 10.7 防止内存操作越界 (58) 10.8 认真处理程序所能遇到的各种出错情况 (59) 10.9 初始化变量 (59) 10.10 数据一致性检查 (59) 10.11 严禁随意更改其它模块或系统的有关设置和配置 (59) 10.12 不能随意改变与其它模块的接口 (59) 软件编程规范 (仅供内部使用) 北京世纪百合科技有限公司 Beijing Centurial Lily Technology Co.,Ltd. 版权所有不得复制 文档修改记录 目录 1.引言 (6) 1.1 目的 (6) 1.2 范围 (6) 2.规范 (6) 2.1 文件 (6) 2.2版面风格 (4) 2.3 标识符命名 (9) 2.4 函数与宏 (11) 2.5 代码的可靠性 (15) 3.附录：通用类型的公共定义 (21) 1.引言 1.1目的 本规范的目的在于增加源代码的可读性，减少程序员对代码理解上的偏差，使程序员能够编写出可靠的代码，降低代码维护成本。 1.2范围 本规范内容涉及范围包括：文件、版面、注释、标识符、变量和结构、函数、宏以及可理解性等。本规范适用于公司开发的所有软件产品。在新软件的编码过程中本规范必须执行。 2.规范 2.1文件 2.1.1头文件的名称一律为小写，格式为“子系统名_文件名.h”。例如： ipf_protocol.h等。 2.1.2头文件的格式如下： 注释头，格式参见软件编程规范； 头文件预编译开关开始，格式为： #ifndef 预编译开关 #define 预编译开关 其中预编译开关格式为：“ _文件名_H”，其中文件名一律大写 头文件内容； 头文件预编译开关结束，格式为： #endif 用来和头文件预编译开关的开始对应。 例如：以下为ipf_ip.h头文件的内容： /************************************************************ Copyright (c) Lily Of The Century Technology Co., LTD. ALL RIGHTS RESERVED Description: // 用于详细说明此程序文件完成的主要功能 *************************************************************/ #ifndef _IPF_IP_H #define _IPF_IP_H ... 软件开发规范 1 排版 11-1：程序块要采用缩进风格编写，缩进的空格数为4个。 说明：对于由开发工具自动生成的代码可以有不一致。 11-2：相对独立的程序块之间、变量说明之后必须加空行。 示例：如下例子不符合规范。 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 应如下书写 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 11-3：较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。 示例： = NO7_TO_STAT_PERM_COUNT_LEN + STAT_SIZE_PER_FRAM * sizeof( _UL ); act_task_table[frame_id * STAT_TASK_CHECK_NUMBER + index].occupied = stat_poi[index].occupied; act_task_table[taskno].duration_true_or_false = SYS_get_sccp_statistic_state( stat_item ); report_or_not_flag = ((taskno < MAX_ACT_TASK_NUMBER) && (n7stat_stat_item_valid (stat_item)) && (act_task_table[taskno].result_data != 0)); 1.程序块采用缩进风格,空格为4个. 说明: 对于开发工具自动生成的代码可以不一致 2.分界符(如大括号{和})应各自占一行并且在同一列,同时与引用它们的语句左 对齐,在方法的开始,类和接口的定义,以及if,for,do,while,switch,case语句都要采用上述缩进 说明: for(…) { …//your code } 3.较长(>80字符)的语句,表达式和参数要分多行,长表达式要在低优先级操作符 划分新行,操作符放在行首,新行要适当缩进,整齐,语句可读. 说明: if(filename != null && new File(logPath+filename).length() < logConfig.getFileSize()) { …//your code } 4.一行只写一条语句 说明: LogFilename wow = null; LogFilename that = null; 5.if,for,do,switch,while,case,default各占一行,它们的执行语句无论多少都要加{} 说明: if(writeToFile) { writeFileThread.interrupt(); } 6.相对独立的程序块,变量,说明要加空行 说明: if(log.getLevel() < log.getRecord()) { return ; } //空行 LogWrite writer; 7.对齐只用空格键,不用TAB键 说明: 以免使用不同的编辑器阅读程序时,因TAB键所设置的空格数不同而造成程序布局不整齐,JBuildr,UltraEdit等编辑环境,支持行首TAB替换成空格,应将该选项打开 8.两个以上的关键字,变量,常量进行对等操作时,操作符之前,之后或前后要加空 格,进行非对等操作时,如果是关系密切的立即操作符,后面不加空格(如.操作符) 说明: 采用这种松散方式编写代码目的是让程序更加清晰,由于空格所产生的清晰性是相对的,所以在已经很清晰的语句中没有必要留空格,如果语句已足够清晰,则括号内侧(即左括号后面和右括号前面)不需要加空格,多重括号间不必加空格,因为java中括号已经是很清晰的标志了.在长句中,如果需要加的空格非常多,那么应该保持整体清晰,而在局部中不加空格,给操作符留空格时不要连续留两个以上空格 9.类属性和方法不要交叉放置,不同存取范围的属性和方法也不要交叉放置 说明: 类定义:{ 类公有属性定义; 类保护属性定义; 类私有属性定义; 类公有方法定义; 类保护方法定义; 类私有方法定义; } 10.源程序的有效注释量必须在30%以上 11.包的注释写入一个名为package.html的html格式的说明文件放入当前路径 12.包的注释内容:本包作用,详细描述本包内容,产品模块名称及版本,公司版本 说明: 华为PCB设计规范 1..1 PCB（Print circuit Board)：印刷电路板。 1..2 原理图：电路原理图，用原理图设计工具绘制的、表达硬件电路中各种器件之间的连接关系的图。 1..3 网络表：由原理图设计工具自动生成的、表达元器件电气连接关系的文本文件，一般包含元器件封装、网络列表和属性定义等组成部分。 1..4 布局：PCB设计过程中，按照设计要求，把元器件放臵到板上的过程。深圳市华为技术有限公司1999-07-30批准，1999-08-30实施。 1..5 仿真：在器件的IBIS MODEL或SPICE MODEL支持下，利用EDA设计工具对PCB的布局、布线效果进行仿真分析，从而在单板的物理实现之前发现设计中存在的EMC问题、时序问题和信号完整性问题，并找出适当的解决方案。深圳市华为技术有限公司1999-07-30批准，1999-08-30实施。 II. 目的 A. 本规范归定了我司PCB设计的流程和设计原则，主要目的是为PCB设计者提供必须遵循的规则和约定。 B. 提高PCB设计质量和设计效率。 提高PCB的可生产性、可测试、可维护性。 III. 设计任务受理 A. PCB设计申请流程 当硬件项目人员需要进行PCB设计时，须在《PCB设计投板申请表》中提出投板申请，并经其项目经理和计划处批准后，流程状态到达指定的PCB设计部门审批，此时硬件项目人员须准备好以下资料： ⒈经过评审的，完全正确的原理图，包括纸面文件和电子件； ⒉带有MRPII元件编码的正式的BOM； ⒊PCB结构图，应标明外形尺寸、安装孔大小及定位尺寸、接插件定位尺寸、禁止布线区等相关尺寸； ⒋对于新器件，即无MRPII编码的器件，需要提供封装资料； 以上资料经指定的PCB设计部门审批合格并指定PCB设计者后方可开始PCB设计。 JAVA编程规范试题 一、判断题（每题2分，共28分） 1、if, for, do, while, case, switch, default 等语句自占一行，且if, for, do, while, switch, case等语句的执行语句无论多少都要加括号{}。 2、包的注释内容要求包括：简述本包的作用、详细描述本包的内容、产品模块 名称和版本、公司版权、生成日期等。 3、类注释部分，描述部分说明该类或者接口的功能、作用、使用方法和注意事 项，每次修改后增加作者、新版本号和当天的日期，@since 表示从那个版本开始就有这个类或者接口，@deprecated 表示不建议使用该类或者接口。4、对于方法内部用throw语句抛出的异常，必须在方法的注释中标明；对于所 调用的其他方法所抛出的异常，在注释中要求说明所有的异常；对于非RuntimeException，即throws子句声明会抛出的异常，必须在方法的注释中标明。 5、类名和接口使用完整的英文单词描述，每个英文单词的首字母使用大写、其 余字母使用小写的大小写混合法。 6、com.huawei.四级部门名称.项目名称，符合包命名规范。 7、不能用异常来做一般流程处理的方式，不要过多地使用异常，异常的处理效 率比条件分支低，而且异常的跳转流程难以预测。 8、划分类的时候，应该尽量把逻辑处理、数据和显示分离，实现类功能的多样 化。 9、一个方法不应抛出太多类型的异常，如果程序中需要分类处理异常，则将异 常根据分类组织成继承关系。 10、switch 语句中的 case 关键字要和后面的常量保持一个空格；如果有特殊 的需要要在switch语句中定义case以外的标签，需要在注释中说明。 11、没有被覆盖的友好方法和没有子类的友好类应该定义成final。 12、简单的类可以通过名字比较两个对象的类，推荐使用 getClass()或者 instanceof()。 13、不要调用 Thread 类的 resume(), suspend(),sleep(), stop() 方法。 DKBA 华为技术有限公司企业技术规范 钢网设计规范 华为技术有限公司发布 版权所有侵权必究 目次 前 言 ................................................................................. .. (3) 1 范围 6 2 规范性引用文件 6 3 术语和定义 6 4 材料、制作方法、文件格式 6 4.1 网框材料 6 4.2 钢片材料 6 4.3 张网用丝网及钢丝网 6 4.4 张网用的胶布，胶 6 4.5 制作方法7 4.6 文件格式7 5 钢网外形及标识的要求7 5.1 外形图7 5.2 PCB居中要求8 5.3 厂商标识内容及位置8 5.4 钢网标识内容及位置8 5.5 钢网标签内容及位置8 5.6 MARK点8 6 钢片厚度的选择9 6.1 焊膏印刷用钢网9 6.2 通孔回流焊接用钢网9 6.3 BGA维修用植球小钢网9 6.4 贴片胶印刷用钢网9 7 焊膏印刷钢网开孔设计9 7.1 一般原则9 7.2 CHIP类元件10 7.2.1 0603及以上10 7.2.2 0402 11 7.3 小外形晶体11 7.3.1 SOT23-1、SOT23-5 11 7.3.2 SOT89 11 7.3.3 SOT143 12 7.3.4 SOT223 12 7.3.5 SOT252，SOT263，SOT-PAK 12 7.4 VCO器件12 7.5 耦合器元件（LCCC) 13 7.6 表贴晶振13 7.7 排阻14 7.8 周边型引脚IC 14 7.8.1 Pitch≤0.65mm的IC 14 7.8.2 Pitch>0.65mm的IC 14 7.9 双边缘连接器14 7.10 面阵型引脚IC 14 7.10.1 PBGA 14 7.10.2 CBGA，CCGA 15 7.11 其它问题15 7.11.1 CHIP元件共用焊盘15 7.11.2 大焊盘15 7.12 通孔回流焊接器件16 7.12.1 焊点焊膏量的计算16 7.12.2 钢网开口的设计17 7.12.3 钢网开口尺寸的计算17 7.13 BGA 植球钢网开口设计18 7.14 特例18 8 印胶钢网开口设计18 8.1 CHIP元件18 8.2 小外形晶体管19 8.2.1 SOT23 19 8.2.2 SOT89 19 8.2.3 SOT143 19 8.2.4 SOT252 19 8.2.5 SOT223 20 FPGA设计流程指南 前言 本部门所承担的FPGA设计任务主要是两方面的作用：系统的原型实现和ASIC的原型验证。编写本流程的目的是： ●在于规范整个设计流程，实现开发的合理性、一致性、高效性。 ●形成风格良好和完整的文档。 ●实现在FPGA不同厂家之间以及从FPGA到ASIC的顺利移植。 ●便于新员工快速掌握本部门FPGA的设计流程。 由于目前所用到的FPGA器件以Altera的为主，所以下面的例子也以Altera为例，工具组合为modelsim + LeonardoSpectrum/FPGACompilerII + Quartus，但原则和方法对于其他厂家和工具也是基本适用的。 目录 1. 基于HDL的FPGA设计流程概述 (1) 1.1 设计流程图 (1) 1.2 关键步骤的实现 (2) 1.2.1 功能仿真 (2) 1.2.2 逻辑综合 (2) 1.2.3 前仿真 (3) 1.2.4 布局布线 (3) 1.2.5 后仿真（时序仿真） (4) 2. Verilog HDL设计 (4) 2.1 编程风格（Coding Style）要求 (4) 2.1.1 文件 (4) 2.1.2 大小写 (5) 2.1.3 标识符 (5) 2.1.4 参数化设计 (5) 2.1.5 空行和空格 (5) 2.1.6 对齐和缩进 (5) 2.1.7 注释 (5) 2.1.8 参考C语言的资料 (5) 2.1.9 可视化设计方法 (6) 2.2 可综合设计 (6) 2.3 设计目录 (6) 3. 逻辑仿真 (6) 3.1 测试程序（test bench） (7) 3.2 使用预编译库 (7) 4. 逻辑综合 (8) 4.1 逻辑综合的一些原则 (8) 4.1.1 关于LeonardoSpectrum (8) 4.1.1 大规模设计的综合 (8) 4.1.3 必须重视工具产生的警告信息 (8) 4.2 调用模块的黑盒子（Black box）方法 (8) 参考 (10) 修订纪录 (10) Java语音编码规范（华为） Java语言编码规范 Prepared by 拟制Date 日期 yyyy-mm-dd Reviewed by 评审人Date 日期 yyyy-mm-dd Approved by Date yyyy-mm-dd Revisi on Record 修订记录 1.范围................................... 2.规范性引用文件............................... 3.术语和定义................................ 4.排版规范.................................. 4.1. 规则................................... 4.2. 建议..... 5. 注释规范 5.1. 规 则........ 5.2. 建议..... 6. 命名规范 6.1. 规 则........ 6.2. 建议..... 7. 编码规范 7.1. 规 则........ 7.2. 建议..... 8. JTEST规 范8.1. 规 则........ 8.2. 建议 .................................... 1.范围 本规范规定了使用Java语言编程时排版、注释、命名、编码和JTEST的规则和建议。 本规范适用于使用Java语言编程的产品和项目。 2.规范性引用文件 下列文件中的条款通过本规范的引用而成为本规范的条款。凡是注日期的引用文 件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本规范，然而，鼓励根据本规范达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本规范。 3.术语和定义 规则：编程时强制必须遵守的原则。 建议：编程时必须加以考虑的原则。 格式：对此规范格式的说明。 说明：对此规范或建议进行必要的解释示例：对此规范或建议从正、反两个方面给出例子。 软件开发行为规范 第一版 深圳市华为技术有限公司 版权所有不得复制 软件开发行为规范 (第一版） 为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以达到过程控制的目的。 与软件开发相关的所有人员，包括各级经理和工程师都必须遵守本软件开发行为规范。对违反规范的开发行为，必须按照有关管理规定进行处罚。 本软件开发行为规范的内容包括：软件需求分析、软件项目计划、概要设计、详细设计、编码、需求管理、配置管理、软件质量保证、数据度量和分析等。 本软件开发行为规范，采用以下的术语描述： ★规则：在软件开发过程中强制必须遵守的行为规范。 ★建议：软件开发过程中必须加以考虑的行为规范。 ★说明：对此规则或建议进行必要的解释。 ★示例：对此规则或建议从正或反两个方面给出例子。 本软件开发过程行为规范由研究技术管理处负责解释和维护。 研究技术管理处 目录 1 软件需求分析 5 2 软件项目计划9 3 概要设计11 4 详细设计14 5 编码18 6 需求管理19 7 软件配置管理21 8 软件质量保证23 9 数据度量和分析25 1 软件需求分析 1-1：软件需求分析必须在产品需求规格的基础上进行，并保证完全实现产品需求规格的定义。 1-2：当产品的需求规格发生变更时，必须修订软件需求规格文档。软件需求规格的变更必须经过评审，并保存评审记录。 1-3：必须对软件需求规格文档进行正规检视。 1-4：软件需求分析过程活动结束前，必须经过评审，并保存评审记录。 1-5：在对软件需求规格文档的正规检视或评审时，必须检查软件需求规格文档中需求的清晰性、完备性、兼容性、一致性、正确性、可行性、易修改性、健壮性、易追溯性、易理解性、易测试性和可验证性、性能、功能、接口、数据、可维护性等内容。 说明：参考建议1-1到1-16。 1-1：采用以下检查表检查软件需求规格文档中需求的清晰性。 1-2：采用以下检查表检查软件需求规格文档中需求的完备性。 华为软件编程规范和范例 〔一〕=====[排版] ]=======. 〔二〕======[注释]=======. 〔三〕=====[标识符命名]=======. 〔四〕=====[可读性]======. 〔五〕=====[变量、结构]=====. 〔六〕=====[函数、过程]=====. 〔七〕=====[可测性]=====. 〔八〕=====[程序效率]=====. 〔九〕=====[质量保证]=====. 〔十〕=====[代码编辑、编译、审查]=====. 〔十一〕=====[代码测试、维护]=====. 〔十二〕=====[宏]=====. 〔一〕========[ 排版]========== 11-1：程序块要采用缩进风格编写，缩进的空格数为4个 说明：对于由开发工具自动生成的代码可以有不一致。 11-2：相对独立的程序块之间、变量说明之后必须加空行 示例：如下例子不符合规范。 Int ni; if (!valid_ni(ni)) { ... // program code } repssn_ind = ssn_data[index].repssn_index; repssn_ni = ssn_data[index].ni; 应如下书写 Int ni; if (!valid_ni(ni)) { ... // program code } repssn_ind = ssn_data[index].repssn_index; repssn_ni = ssn_data[index].ni; 11-3：较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读 示例： perm_count_msg.head.len = NO7_TO_STAT_PERM_COUNT_LEN 华为软件开发规范 软件开发规范 1 排版 11-1：程序块要采用缩进风格编写，缩进的空格数为4个。 说明：对于由开发工具自动生成的代码可以有不一致。 11-2：相对独立的程序块之间、变量说明之后必须加空行。 示例：如下例子不符合规范。 if (!valid_ni(ni)) { ... // program code } repssn_ind = 仅供内部使用2 ssn_data[index].repssn_index; repssn_ni = ssn_data[index].ni; 应如下书写 if (!valid_ni(ni)) { ... // program code } repssn_ind = ssn_data[index].repssn_index; repssn_ni = ssn_data[index].ni; 11-3：较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。 示例： perm_count_msg.head.len = NO7_TO_STAT_PERM_COUNT_LEN + STAT_SIZE_PER_FRAM * sizeof( _UL ); 仅供内部使用3 act_task_table[frame_id * STAT_TASK_CHECK_NUMBER + index].occupied = stat_poi[index].occupied; act_task_table[taskno].duration_true_or_false = SYS_get_sccp_statistic_state( stat_item ); report_or_not_flag = ((taskno < MAX_ACT_TASK_NUMBER) && (n7stat_stat_item_valid (stat_item)) && (act_task_table[taskno].result_data != 0)); 仅供内部使用4 Java语音编码规范(华为) 【最新资料，WORD文档，可编辑修改】 Java语言编码规范 Prepared by 拟制Date 日期 yyyy-mm-dd Reviewed by 评审人Date 日期 yyyy-mm-dd Approved by 批准Date 日期 yyyy-mm-dd Revision Record 修订记录 Table of Contents 目录 1.范围 本规范规定了使用Java语言编程时排版、注释、命名、编码和JTEST的规则和建议。 本规范适用于使用Java语言编程的产品和项目。 2.规范性引用文件 下列文件中的条款通过本规范的引用而成为本规范的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本规范，然而，鼓励根据本规范达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本规范。 3.术语和定义 规则：编程时强制必须遵守的原则。 建议：编程时必须加以考虑的原则。 格式：对此规范格式的说明。 说明：对此规范或建议进行必要的解释。 示例：对此规范或建议从正、反两个方面给出例子。 4.排版规范 4.1.规则 4.1.1.*程序块要采用缩进风格编写，缩进的空格数为4个。 说明：对于由开发工具自动生成的代码可以有不一致。 4.1.2.*分界符（如大括号‘{’和‘}’）应各独占一行并且位于同一列， 同时与引用它们的语句左对齐。在函数体的开始、类和接口的定义、以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。 示例：如下例子不符合规范。 for (...) { ... .) { ... . .) { ... .) { ... . ength() < ()) { 4.1.3.... ，后不应加空格。 说明：采用这种松散方式编写代码的目的是使代码更加清晰。 由于留空格所产生的清晰性是相对的，所以，在已经非常清晰的语句中没有必要再留空格，如果语句已足够清晰则括号内侧(即左括号后面和右括号前面)不需要加空格，多重括号间不必加空格，因为在Java语言中括号已经是最清晰的标志了。 在长语句中，如果需要加的空格非常多，那么应该保持整体清晰，而在局部不加空格。给操作符留空格时不要连续留两个以上空格。 示例： （1）逗号、分号只在后面加空格。 int a, b, c; （2）比较操作符, 赋值操作符"="、"+="，算术操作符"+"、"%"，逻辑操作符"&&"、"&"，位域 Panorama系统程序开发规范之二 1.匈牙利命名规则 变动前缀类型 a Array b Boolean by Byte c Char //有符号型字符 cb Char Byte //无符号型字符（没多大用处） cr ColorRef //颜色参考值 cx,cy Length of x,y (ShortInt) //坐标差（长度） dw Double Word fn Function h Handle i Integer m_ Member of a class n Short Integer np Near Pointer p Pointer lp Long Pointer ×(str) s String sz String with Zero End //以字符'\0'结尾的字符串 tm Text //文本内容 w Word x,y Coordinate //坐标 2.Panorama系统的命名约定 2.1 VC中变量命名时的前缀约定 Array a... //例：CStringArray saText BOOL b... UINT n... int i... short n... long l... WORD w... DWORD dw... float f... char c... char* psz... TCHAR* psz... LPCTSTR lpsz... CString str... COLORREF cr... LPLOGPALETTE lp... (包括LP开头的类型都是这样) POINT pt... CPoint pt... HANDLE h... HGLOBAL h... (包括H开头的类型都是这样) 说明： 1.如果是指向上述类型的指针，就在上面规范前加"p" ; 2.如果是指向上述类型的双重指针，就在上面规范前加"pp" ; 3.如果是类成员变量，则在上面规范前加"m_"; 4.全局变量,则在上面规范前加"g_"; 5.在类型前加了"const",命名约定不变; 2.2 VC中变量命名时的后缀约定 1.MFC类 CWnd* p...Wnd 省去的地方一般为该类的用途(如果是某一个类的成员，则还应该在前加"m_")又如：CView* p...View 2.3 局部变量应尽量易懂简洁，使用常见的变量，如Num,nCount,i,j,k,n,len,pos, offset,nReadNum,index,nRet,ret, string,filename临时变量，如ltmp,ftmp,tmpStr,tempStr 。。。 2.4 函数命名也应该见名知意。如CalcAllDataStyle(),ReadDocDataFromTime(),GetIndexInfo() 常见的函数Init_, Open_, Create_, Get_, Set_, Read_, Load_, Write_, Start_, Stop_, Check_,华为软件编程规范
华为JAVA编程规范
华为Java语言编码规范标准
华为软件编程规范.doc
华为公司招聘职位要求
华为代码规范文档
华为软件编程地要求规范
华为软件开发规范
华为JAVA编码规范
公司版本信息 PCB设计规范-华为
华为JAVA编程规范试题
华为钢网设计规范(网络软件)
华为fpga设计规范(Verilog Hdl)
Java语音编码规范华为
华为软件开发行为规范
华为软件编码规范
华为软件开发规范
Java语音编码规范 华为
华为程序开发规范
相关主题
文本预览