### vc编码规范知识点详解
#### 一、总体原则
**1. 使用标准英文单词或缩写**
- **基本原则**：在所有命名中，都应使用标准的英文单词或缩写来描述，不得使用拼音或拼音缩写，除非是描述中文特有的内容（如半角、全角、声母、韵母等）。
- **目的**：提高代码的可读性和国际通用性。
**2. 达意原则**
- **基本原则**：所有命名都应遵循达意原则，即名称应含义清晰、明确。
- **目的**：确保代码易于理解和维护。
**3. 控制长度**
- **基本原则**：所有命名都不宜过长，应控制在规定的最大长度以内。
- **目的**：避免因命名过长导致的阅读困难。
**4. 尽量使用全称**
- **基本原则**：所有命名都应尽量使用全称而非缩写。
- **目的**：增加代码的可读性和减少理解成本。
**5. 缩写的使用**
- **基本原则**：如果命名使用缩写，则应该使用《通用缩写表》中的缩写；原则上不推荐使用《通用缩写表》以外的缩写，如果使用，则必须对其进行注释和说明。
- **目的**：保持一致性，便于理解和维护。
**6. 程序结构清晰**
- **基本原则**：程序结构清晰，简单易懂，单个函数的程序行数不得超过200行。
- **目的**：提高代码的可读性和可维护性。
**7. 避免冗余**
- **基本原则**：代码精简，避免垃圾程序。
- **目的**：减少无用代码，提高执行效率。
**8. 使用标准库函数**
- **基本原则**：尽量使用标准库函数和公共函数。
- **目的**：提高代码质量，减少错误。
**9. 全局变量的使用**
- **基本原则**：不要随意定义全局变量，尽量使用局部变量。
- **目的**：降低模块间的耦合度，提高代码的可维护性。
**10. 使用括号**
- **基本原则**：使用括号以避免二义性。
- **目的**：确保代码逻辑清晰，避免语法错误。
#### 二、可读性要求
**1. 保持注释与代码完全一致**
- **基本原则**：保持注释与代码完全一致。
- **目的**：确保代码的变更能够及时反映在注释中，方便后续开发人员理解。
**2. 文件头说明**
- **基本原则**：每个源程序文件都有文件头说明，说明规格见规范。
- **目的**：提供文件的基本信息，方便管理和追踪。
**3. 函数头说明**
- **基本原则**：每个函数都有函数头说明，说明规格见规范。
- **目的**：帮助理解函数的功能和使用方法。
**4. 变量注释**
- **基本原则**：主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。
- **目的**：提高代码的可读性，方便其他开发人员快速理解变量的用途。
**5. 常量定义说明**
- **基本原则**：常量定义（DEFINE）有相应说明。
- **目的**：确保常量的定义清晰明了。
**6. 处理过程注释**
- **基本原则**：处理过程的每个阶段都有相关注释说明。
- **目的**：帮助理解算法流程。
**7. 算法注释**
- **基本原则**：在典型算法前都有注释。
- **目的**：提高代码的可读性。
**8. 缩进规范**
- **基本原则**：利用缩进来显示程序的逻辑结构，缩进量一致并以Tab键为单位，定义Tab为4个字节。
- **目的**：确保代码格式统一，提高可读性。
**9. 循环、分支层次**
- **基本原则**：循环、分支层次不要超过五层。
- **目的**：避免过于复杂的嵌套结构，提高代码的可读性和可维护性。
**10. 注释位置**
- **基本原则**：注释可以与语句在同一行，也可以在上行。
- **目的**：提高代码的灵活性，方便阅读。
**11. 注释范围**
- **基本原则**：注释的作用范围可以为：定义、引用、条件分支以及一段代码。
- **目的**：确保代码的关键部分都有适当的注释。
#### 三、正确性与容错性要求
**1. 程序正确性优先**
- **基本原则**：程序首先是正确，其次是优美。
- **目的**：确保程序功能准确无误。
**2. 错误检查**
- **基本原则**：在编写完一段程序后，应先回头检查。
- **目的**：尽可能发现并修复错误。
**3. 修改后的验证**
- **基本原则**：改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。
- **目的**：防止引入新的问题。
**4. 变量初始化**
- **基本原则**：所有变量在调用前必须被初始化。
- **目的**：避免使用未初始化的变量导致程序运行出错。
**5. const变量**
- **基本原则**：不进行修改的变量，一律使用const来定义。
- **目的**：提高代码的安全性和可读性。
**6. 动态变量管理**
- **基本原则**：动态申请的变量，在使用完之后必须立刻释放，并赋值为NULL。
- **目的**：防止内存泄漏。
**7. 异常处理**
- **基本原则**：对于关键性的代码，一律使用try、catch来进行异常处理。
- **目的**：增强程序的健壮性。
**8. 返回值类型**
- **基本原则**：接口函数的返回值类型一律使用HRESULT，关于HRESULT的描述见附录二。
- **目的**：统一返回值类型，方便错误处理。
**9. 用户输入检查**
- **基本原则**：对所有的用户输入，必须进行合法性检查。
- **目的**：防止非法数据导致程序崩溃。
**10. 浮点数比较**
- **基本原则**：不要比较浮点数的相等，如：10.0*0.1==1.0，不可靠。
- **目的**：避免由于浮点数精度问题导致的错误。
**11. 错误处理**
- **基本原则**：程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否逻辑锁定、打印机是否联机等。
- **目的**：提高程序的稳定性和可靠性。
**12. 单元测试**
- **基本原则**：单元测试也是编程的一部分，提交联调测试的程序必须通过单元测试。
- **目的**：确保代码的质量。
#### 四、可重用性要求
**1. 抽象公共组件**
- **基本原则**：重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。
- **目的**：提高代码的复用率。
**2. OO设计**
- **基本原则**：公共控件或类应考虑OO思想，减少外界联系，考虑独立性或封装性。
- **目的**：提高代码的可扩展性和可维护性。
**3. 使用模板**
- **基本原则**：公共控件或类应建立使用模板。
- **目的**：简化开发流程，提高开发效率。
**4. 字符串处理**
- **基本原则**：为了UNICODE的移植性，所有字符串在定义时都使用_T(“…”)，定义字段串变量时，一律使用带T的类型，在使用字符串处理的函数时，优先使用支持UNICODE函数。
- **目的**：提高字符串处理的兼容性和移植性。
**5. 条件编译**
- **基本原则**：在编译各个版本时，尽量使用DEFAULT来进行条件编译。
- **目的**：提高编译的灵活性和效率。
#### 五、具体规范
**1. 工程名**
- **基本原则**：不强制统一。
- **目的**：灵活处理工程命名。
**2. 文件名**
- **基本原则**：基于工程名，开头3个字母应表明与哪一个工程相关；后面的字母应能够区别不同的功能；不区分大小写；长度不限于8.3格式，建议不多于30个字符；若文件用于定义和实现类，建议文件名与类名保持一致。
- **目的**：提供清晰的文件命名规则，方便管理和查找。
**3. 函数名**
- **基本原则**：参照Windows API的命名规范；函数名应清晰反映函数的功能、用途；函数名最长不得超过30个字符；函数名第一个字母必须大写；参数必须说明输入输出；对返回值做出详细的描述。
- **目的**：确保函数命名规范且易于理解。
**4. 变量名**
- **基本原则**：原则上，变量名的命名遵从匈牙利记法。变量名最长不得超过20个字符；格式：[m|s|g]type[classname|structname]variablename；解释：m_：类的成员变量；ms_：类的静态成员变量；g_：普通全局变量；gs_：静态全局变量；类型缩写（type）见附录三；循环内的计数变量使用i、j、n、m等一个字母。
- **目的**：确保变量命名一致且易于识别。
**5. 类名**
- **基本原则**：必须以大写"C"开头，后面字母反映具体含义，以清晰表达类的用途和功能为原则；接口必须以大写"I"开头，代表Interface；当名称由多个单词构成时，每一个单词的第一个字母必须大写。
- **目的**：提供清晰的类命名规则，便于识别和理解。
**6. 结构名、宏名、枚举名、联合名**
- **基本原则**：全部大写，定义时一律使用typedef；当名称由多个单词构成时，单词之间用“_”隔开；枚举名加小写前缀"em"。
- **目的**：确保这些命名的一致性和清晰度。
通过以上详细说明，我们可以看到VC编码规范覆盖了从总体原则到具体实施细节的各个方面，旨在提高代码的质量、可读性和可维护性。遵循这些规范，可以帮助开发者写出更加优秀、高效的软件产品。
