审查代码规范(C++)

审查代码规范 C++ 1. 范围 3 2. 规范性引用文件 3 3. 术语和定义 3 4. 开发工具 3 5. 目录结构 4 6. 布局规范 5 6.1. 对齐 5 6.2. 代码行内的空格 7 6.3. 空行 8 6.4. 代码行 9 6.5. 长行拆分 10 6.6. 注释 11 6.6.1. 概述 11 6.6.2. 基本规则 11 6.6.3. 函数注释（序言性注释） 13 6.6.4. 程序注释（功能性注释） 15 7. 命名规则 17 7.1. 共性规则 17 7.2. 一般命名规则 17 8. 文件结构 19 8.1. 概述 19 8.2. 版权和版本的声明 19 8.3. 头文件的结构 20 8.4. 定义文件的结构 21 9. 注意事项 22 9.1. 布尔变量与零值比较 22 9.2. 整型变量与零值比较 23 9.3. 浮点变量与零值比较 23 9.4. 指针变量与零值比较 23 9.5. 第三方工具的使用 23 10. SQL代码规范 24 10.1. SQL语句格式 24 10.2. SQL性能优化 24 10.2.1. WHERE子句中的连接顺序 24 10.2.2. SELECT子句中避免使用“*” 24 10.2.3. 减少访问数据库的次数 24 10.2.4. 使用DECODE函数来减少处理时间 25 10.2.5. 用Where子句替换HAVING子句 26 10.2.6. 减少对表的查询 26 10.2.7. 使用表的别名(Alias) 27 10.2.8. 用EXISTS替代IN 27 10.2.9. 用索引提高效率 29 10.2.10. 避免在索引列上使用计算 31 10.2.11. 避免在索引列上使用IS NULL和IS NOT NULL 31 10.2.12. 使用UNION-ALL和UNION 32 ### 审查代码规范(C++) #### 一、范围 本规范主要针对C/C++编程领域，明确了在软件开发过程中需要遵循的一些基本原则和技术规范。它不仅涵盖了基础的编程风格指导，还包括了对开发环境的设置、目录结构的设计以及具体的代码布局等方面的要求。 #### 二、规范性引用文件 为了确保本规范的权威性和准确性，以下列文件为基础进行了引用： - GB/T5271.1-2000信息技术词汇第1部分：基本术语 - GB/T5271.7-1986数据处理词汇07部分：计算机程序设计 - GB/T5271.15-1986数据处理词汇15部分：程序设计语言 这些文件为本规范提供了必要的理论支持和技术背景，帮助开发者更好地理解和应用各项规定。 #### 三、术语和定义 本规范中的术语和定义基于以下标准： - GB/T5271.1-2000 - GB/T5271.7-1986 - GB/T5271.15-1986 这些定义有助于明确文中出现的专业词汇的具体含义，从而确保读者能够准确理解各项规范的具体要求。 #### 四、开发工具 - **编译器**：GCC4.4.4。选择GCC作为编译器，是因为它具有良好的跨平台兼容性，同时支持多种编程语言，对于C/C++开发者来说是非常理想的工具。 - **版本控制**：SVN (Subclipse)。版本控制系统是团队协作的重要组成部分，SVN能够帮助开发者有效管理源代码的变更历史，方便追踪问题和回溯修改。 - 提交代码时需附带清晰的日志说明，以记录每一次变更的具体内容。 - 提交粒度应该控制在一个完整的功能实现，避免过于频繁的琐碎提交。 - 提交日志应当使用统一的动词开头，例如“添加”、“移除”或“修改”，这样能够更清晰地表达变更内容。 - **数据库**：ORACLE10.2.1。对于涉及数据库操作的应用程序而言，使用稳定的数据库系统是至关重要的。 #### 五、目录结构 - **一级目录**：以各业务组的一级模块英文简称命名。 - **二级目录**：在一级目录下，以二级模块英文简称命名，主要用于区分不同的业务需求。 - **三级目录**：在二级目录下，以三级模块英文简称命名，用于区分不同的编码需求。若无需建立三级目录，则可在二级目录下直接存放文件。 - **四级目录**：原则上禁止建立四级目录，除非使用某些第三方工具生成代码时有必要。 - **目录命名**：所有目录名称均应使用小写字母。 - **文件与目录共存**：若在同一目录层级内需要同时存放文件和子目录，应严格参照特定的规定。 - **公共目录**：建议在二级和三级目录下设立common目录来存放公共模块。 #### 六、布局规范 - **对齐**：确保代码中的元素在视觉上整齐排列，增强代码的可读性。 - **代码行内的空格**：合理使用空格可以使代码更加清晰，便于阅读。例如，在操作符前后加空格。 - **空行**：适当使用空行分割逻辑上独立的代码块，提升代码的可读性。 - **代码行**：每行代码不宜过长，通常不超过80个字符，以保持良好的视觉效果。 - **长行拆分**：对于超出一行长度限制的语句，应该合理拆分成多行，以保持代码的整洁。 - **注释** - **概述**：注释应当简洁明了，提供必要的上下文信息。 - **基本规则**：注释应当放在被解释代码的上方或右侧，避免冗余。 - **函数注释**：为函数提供描述性的序言性注释，包括参数说明、返回值等。 - **程序注释**：为复杂的算法或逻辑提供功能性注释，帮助读者理解其实现原理。 #### 七、命名规则 - **共性规则**：命名应当直观反映其用途，避免使用缩写或含义模糊的名称。 - **一般命名规则**：变量、函数等命名应遵循一定的约定，例如使用驼峰式命名法或下划线分隔等方式。 #### 八、文件结构 - **概述**：文件结构应遵循一致的模式，以便于管理和维护。 - **版权和版本声明**：文件顶部应包含版权信息和版本号声明。 - **头文件结构**：定义头文件的基本结构，确保头文件的一致性和标准化。 - **定义文件结构**：定义源文件的基本结构，包括必要的注释、头文件包含等。 #### 九、注意事项 - **布尔变量与零值比较**：推荐使用布尔运算符进行比较而非数值比较。 - **整型变量与零值比较**：同样推荐使用布尔运算符。 - **浮点变量与零值比较**：由于浮点数的精度问题，推荐使用误差范围来进行比较。 - **指针变量与零值比较**：推荐使用`nullptr`代替`NULL`进行比较。 - **第三方工具的使用**：谨慎选择并使用第三方工具，确保它们的安全性和稳定性。 #### 十、SQL代码规范 - **SQL语句格式**：保持SQL语句的格式一致，提高可读性。 - **SQL性能优化** - **WHERE子句中的连接顺序**：合理安排连接顺序可以显著提升查询速度。 - **SELECT子句中避免使用“*”**：指定需要的字段而非使用通配符，以减少不必要的数据传输。 - **减少访问数据库的次数**：通过批处理等方式减少数据库访问次数。 - **使用DECODE函数来减少处理时间**：利用DECODE函数简化条件判断逻辑。 - **用Where子句替换HAVING子句**：HAVING子句通常会导致额外的计算开销。 - **减少对表的查询**：通过索引等技术手段减少不必要的表扫描。 - **使用表的别名**：别名可以使SQL语句更加简洁易读。 - **用EXISTS替代IN**：当判断是否存在某项数据时，使用EXISTS通常比IN更快。 - **用索引提高效率**：合理使用索引可以极大地提升查询性能。 - **避免在索引列上使用计算**：这会导致索引失效，增加查询时间。 - **避免在索引列上使用IS NULL和IS NOT NULL**：同样会导致索引失效。 - **使用UNION-ALL和UNION**：根据实际情况选择使用UNION-ALL或UNION以提高查询效率。 这份C/C++代码审查规范全面覆盖了从开发工具的选择到具体编码实践的各个方面，旨在帮助开发者编写出高质量、可维护的代码。通过遵循这些规范，可以显著提升软件项目的整体质量和技术水平。