一般代码规范

代码规范：

1.要求

1代码简洁精炼，美观，可读性好，高效率，高复用，可移植性好，高内聚，低耦合，没有冗余，不符合这些原则，必须特别说明。

2.规范性，代码有规可循。特殊排版、特殊语法、特殊指令，必须特别说明。

2.排版

2.1.包含头文件

a) 系统头文件和用户自定义头文件应区分开，不应交叉包含。  
b) 系统头文件应采用稳定的目录结构，并使用包含子路径的方式，例如 `#include "sub/test.h"`。  
c) 系统头文件应使用 `#include` 指令进行包含。  
d) 自定义头文件应使用 `#include "xxx.h"` 指令进行包含。  
e) 仅引用实际需要的头文件。  
f) 对于所有 `#include` 的文件名，应视为大小写敏感。在可以使用声明的情况下，应优先使用声明。

2.2. h和cpp文件

a) 头文件应命名为 `.h`，内联文件应命名为 `.inl`，C++ 源文件应命名为 `.cpp`。  
b) 文件名应具有描述性，避免使用无意义的名称（例如 `XImage.cpp`）。命名应在系统中保持一致。  
c) 头文件应使用 `#ifdef` 控制包含块，除非有特殊情况。  
d) 头文件中的 `#endif` 应添加行末注释以标识对应的 `#ifdef`。  
e) 在头文件中，组织结构应为：首先是全局函数，其次是宏定义代码块，然后是全局变量和常量，接着是类型定义，最后是类定义和内联部分。  
f) 在 C++ 源文件中，组织结构应为：首先是包含指令，其次是宏定义，接着是全局变量，最后是函数定义。

2.3.文件结构

a)文件应包含文件头注释和内容。 b)函数体类体之间原则上用1个空行，特殊情况下可用一个或者不需要空行。

2.4.空行

文件头、控制块，#include部分、宏定义部分、class部分、全局常量部分、全局变量部分、函数和函数之间，用一个空行。'

3.注释

3.1.文件头注释

作者，文件名称，文件说明，生成日期(可选)，提供模板

3.2.函数注释

a) 关键函数需要添加注释，说明其功能，使用注释模板进行标注。  
b) 特殊函数参数需要说明其目的、责任方及释放方式。  
c) 除非特殊情况，注释应放在代码之前，不应放在代码行之后。  
d) 每个`#else`或`#endif`应加上行末注释。  
e) 关键代码的注释包括赋值、函数调用、表达式、分支等。  
f) 对于尚未实现或需优化的代码，应加上 `// TODO ...` 或类似注释。  
g) 调试代码应标注 `// DEBUG` 或类似注释。  
h) 需要特别关注的代码应标注 `// NOTE ...` 或类似注释。  
i) 对于较大的代码块结尾，如 `for`、`while`、`do` 等，应加上 `// end for|while|do` 或类似注释。

4.命名

4.1.原则

a) 保持一致性：在编写子模块或派生类时，应遵循基类或整体模块的命名风格，确保整个模块中的命名风格一致。  

b) 标识符组成：标识符应由英文单词或其组合构成，直观易读，词汇应准确并避免使用拼音。  

c) 长度与信息量：在保持标识符含义明确的同时，应尽量缩短其长度。  

d) 避免相似性：不要使用仅通过大小写区分的标识符，如 "i" 和 "I" 或 "function" 和 "Function"。  

e) 避免作用域冲突：避免在不同级别的作用域中使用相同名字的变量，尽管不同作用域不会产生语法错误，但容易引起误解。  

f) 正确命名互斥标识符：对具有互斥意义的标识符使用合适的反义词，如 "minValue" 和 "maxValue"、"getName()" 和 "setName()"。  

g) 避免数字编号：尽量避免在名字中使用数字编号，如 "Value1"、"Value2" 等，除非逻辑上确实需要编号。

4.2.函数

a) 类的函数名称应使用首字母小写的形式，如 `handleColor`，而不推荐使用 `HandleColor`。尽量避免在除标准 C 风格代码和标准模板库之外的代码中使用下划线，例如 `handle_color`，以避免与系统或标准函数重名，并使作用范围不易辨识。  

b) 当函数参数较多时，应考虑使用结构体代替，函数参数数量应不超过 6 个。  

c) 如果无法避免参数过多的情况，应在排版上考虑将相似含义的参数放在同一行，参数名应竖向对齐，甚至可以每个参数单独占一行。

4.3.变量

a)变量命令方式应采用驼峰命令方式。例如handleColor；当类型叠加时，应以最能够表现变量类型的打头方式，例如int类型的指针，应采用p打头；指针类型的数组，应采用a打头，数组的指针因采用p打头。

4.4.类型名

a) 类名和结构体名的首字母应大写，例如 `MyClass` 和 `MyStruct`。  
b) 类和对象的名称应使用名词。  
c) 枚举定义应以 `E_` 开头，全部大写，并用下划线分隔单词，如 `E_TYPE_STUDENT_INFO`。枚举值应以枚举类型名为前缀，例如 `E_TYPE_STUDENT_INFO_NUMBER`。  
d) 宏定义应以 `DEF_` 开头，全部大写，并用下划线分隔单词，如 `DEF_TYPE_ID`。

4.5.风格兼容性

a)对于移植的或者开源的代码，可以沿用原有风格，不用C++的命名规范。

5.1.Tab和空格

a)每一行开始处的缩进只能用4个空格，不能用Tab，输入内容之后统一用空格。 b)在代码行的结尾部分不能出现多余的空格。 c)不要在"::","->","."前后加空格。 d)不要在"，","；"之前加空格。

5.2.类型定义

a) 类、结构、枚举和联合的 `{` 应另起一行。  
b) 函数体的 `{` 也应另起一行，并且 `{` 之前的缩进应与上一行对齐。  
c) 函数体内，除非有特殊情况，不应出现两个连续的空行。  
d) 函数体内不应包含宏定义指令，除非该宏定义仅在该函数内使用。  
e) 在一个函数体内，逻辑上紧密相关的语句之间不应插入空行，而其他地方应使用空行进行分隔。

5.3.代码块

a)"if"、"for"、"while"、"do"、"try"、"catch" 等语句自占一行，执行语句不得紧跟其后。不论执行语句有多少都要加 "{ }" 。这样可以防止书写和修改代码时出现失误。 b)"if"、"for"、"while"、"do"、"try"、"catch" 的括号和表达式，括号可紧挨关键字，这样强调的是表达式。

5.4.代码行

a) 每行代码应只执行一项操作，如定义一个变量或写一条语句，这样代码更易读，也便于添加注释。  
b) 多行变量定义时，为了代码排版的美观，可以将变量竖向对齐。  
c) 代码行的最大长度应控制在一定字符数以内，以便在当前屏幕上完全显示。建议控制在80个字符以内。

5.5.宏

a)不要用分号结束宏定义。 b)能使用函数来解决的问题，不要使用宏，方便调式。 5.6.goto a)不要用goto。

6.类型

a) 在定义指针和引用时，将 `*` 和 `&` 紧跟在变量名后面。  
b) 除非必要，否则尽量避免使用浮点数。  
c) 使用 `typedef` 简化程序中的复杂类型语法。  
d) 避免定义无名称的类型，例如 `enum TState { EIdle, EActive };`。  
e) 尽量减少使用 `union`，如果必须使用，则选择简单数据类型作为成员。  
f) 使用 `enum` 替代一组相关的常量。  
g) 避免使用魔鬼数字。  
h) 尽量用引用替代指针。  
i) 定义变量后立即初始化，避免等到使用时才初始化，并在需要使用到变量时才定义变量。  
j) 如果有更优雅的解决方案，避免使用强制类型转换，如 `dynamic_cast`，尽量使用多态。

7.表达式

a) 避免在表达式中使用赋值语句。  
b) 避免对浮点类型进行等于或不等于的判断。  
c) 不要对枚举类型进行运算后再赋值给枚举变量。  
d) 在循环中不要修改循环计数器的值。  
e) 使用 `if (p)` 来检测空指针。  
f) 使用 `if (!p)` 来检测非空指针。

8.1.引用

a)引用类型作为返回值：函数必须返回一个存在的对象。 b)引用类型作为参数：调用者必须传递一个存在的对象。

8.2.返回值

a)除开void函数，构造函数，析构函数，其它函数必须要有返回值。在函数的实现中，每个分支必须显示返回return。 b)当函数返回引用或指针时，用文字描述其有效期。

8.3.内联函数

a)内联函数应将函数体放到类体外。 b)只有简单的函数才有必要设计为内联函数，复杂业务逻辑的函数不要这么做。 c)虚函数不要设计为内联函数。

8.4.函数参数

a) 对于只读取参数内容而不修改它的情况，使用常量引用。  
b) 对于需要修改参数内容或通过参数返回结果的情况，使用非常量引用。  
c) 对于简单数据类型，使用传值方式。  
d) 对于复杂数据类型，使用引用或指针方式。  
e) 输入参数应排在前面，输出参数应排在后面（默认参数除外）。  
f) 除了通用库函数外，尽量避免使用默认参数。

9.类

9.1.整体结构

a)按照 public, protected, private 的顺序分块。哪一块没有，就直接忽略。 b)每一块中，按照下面顺序排列 1)typedef，enum，struct，class 定义的嵌套类型 2)常量 3)构造函数 4)析构函数 5)成员函数,含静态成员函数 6)数据成员,含静态数据成员 c).cpp 文件中，函数的实现尽可能和声明次序一致。

9.2.构造函数

a) 构造函数的初始化列表应按照类成员变量的定义顺序排列。 b) 初始化列表中的每个项应占用单独一行。 c) 避免在初始化列表中用一个成员来初始化另一个成员。 d) 构造函数应确保初始化所有成员，尤其是指针。 e) 不要在构造函数和析构函数中抛出异常。

9.3.纯虚函数

接口类的虚函数应设计为纯虚函数。

9.4.构造和析构函数

a)如果类可以继承，则应将类析构函数设计为虚函数。 b)如果类不允许继承，则应将类析构函数设计为非虚函数。 c)如果类不能被复制，则应将拷贝构造函数和赋值运算符设计为私有的。 d)如果为类设计了构造函数，则应有析构函数。

9.5.成员变量

a)尽量避免使用mutable（mutex除外）和volatile。 b)尽量避免使用公有成员变量。

9.6.成员函数

当然，以下是对这些规范的改写：

a) **确保类的接口既简洁又完整：**  
   设计类时，要确保其接口尽可能简洁，同时涵盖所有必要功能。

b) **优先使用 `const` 成员函数：**  
   尽量将成员函数声明为 `const`，以保证对象状态不会被修改。

c) **避免不必要的非虚函数重定义：**  
   只有在确有需要时，才重定义非虚函数，以减少潜在的复杂性和错误。

d) **使用 `override` 标记虚函数重写：**  
   在子类中重写父类的虚函数时，应使用 `override` 关键字，这样编译器可以确保虚函数正确重写。

e) **使用 `final` 阻止虚函数重写：**  
   若不希望虚函数被进一步重写，可以在函数声明后添加 `final` 关键字，以防止子类对其进行重写。

9.7.继承

a)继承必须满足IS-A的关系，HAS-A应采用包含。 b)虚函数不要采用默认参数。 c)除非特别需要，应避免设计大而全的虚函数，虚函数功能要单一。 d)除非特别需要，避免将基类强制转换成派生类。

10.错误处理

当然，以下是对这些内存和指针相关规范的改写：

a) **释放内存后将指针设为 `nullptr`：**  
   在释放内存后，将指针赋值为 `nullptr`，以避免出现悬挂指针问题。

b) **使用指针前验证其有效性：**  
   在使用指针之前，应该检查其是否有效，并处理可能的空指针情况，除非在特定的组合模式下不需要此步骤。

c) **验证数组索引的有效性：**  
   在访问数组元素之前，应确保索引在有效范围内，并妥善处理无效索引的情况。

d) **采用卫句风格编写代码：**  
   优先处理所有可能的错误情况，然后再处理正常逻辑，以提高代码的健壮性和可读性。

11.性能

a) 在头文件中使用前向声明，如 class M;，代替包含头文件。 b) 尽量在 for 循环之前计算估值表达式。 c) 避免在循环体内部定义对象。 d) 尽量避免代价高昂的对象拷贝。 e) 避免生成大型临时对象。 f) 注意处理大尺寸对象数组。 g) 尽量使用标准库中的封装算法。

《数学之美》第一章读后感

第一章：文字和语言vs数字和信息。  

这一章节探讨了语言、文字与信息的关系，揭示了它们如何影响信息的传递和保存。远古时期，人们用声音传递信息，这一过程与现代通信原理基本一致：发声是编码，空气传播是信道，接收者理解是解码。随着语言和词汇的复杂化，人类发展出文字作为信息的记录工具。最早的文字形式，如非洲的图形记录，标志着概念的分类和总结，而这些概念的聚类与现代计算机处理的聚类有相似之处。文字系统的演变，如从象形文字到拼音文字，显示了人类从物体的具体描述到抽象概念的进步。信息的冗余，如罗塞塔石碑上的重复内容，保证了信息的安全性。不同的计数系统，如十进制和二十进制，反映了不同文明的计数方法，而阿拉伯数字的引入则大大简化了数学运算。书写材料的珍贵促使古文字简短且难懂，但口语与现代白话相差不大，这符合信息科学中的压缩和解压缩原理。犹太人发明的校验码和莎士比亚原著的语言影响也强调了语言和信息科学的紧密关系。 以上就是我总结的第一章的内容。这部分内容用浅显易懂的语言概括讲述了语言、文字、数字、信息的历史与联系，内容全面而丰富，也是我的《数学之美》启蒙章节。