代码规范与《数学之美》第一章读后感

听风如旧 2024-09-22 21:55:03

编码规范总结：

一、文件排版方面

1. 包含头文件

　• 先系统头文件，后用户头文件。
　• 系统头文件，稳定的目录结构，应采用包含子路径方式。
　• 自定义头文件，不稳定目录结构，应在dsp中指定包含路径。
　• 系统头文件应用：#include <xxx.h>
　• 自定义同文件应用：#include "xxx.h"
　• 只引用需要的头文件。

2. h和cpp文件

　• 头文件命名为.h，内联文件命名为.inl；C++文件命名为*.cpp
　• 文件名用大小写混合，或者小写混合。例如DiyMainview.cpp，infoview.cpp。不要用无意义的名称：例如XImage.cpp；SView.cpp；xlog.cpp；
　• 头文件除了特殊情况，应使用#ifdef控制块。
　• 头文件#endif应采用行尾注释。
　• 头文件，首先是包含代码块，其次是宏定义代码块，然后是全局变量，全局常量，类型定义，类定义，内联部分。
　• CPP文件，包含指令，宏定义，全局变量，函数定义。

3. 文件结构

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

4. 空行

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

二、注释方面

1. 文件头注释

　• 作者，文件名称，文件说明，生成日期(可选)

2. 函数注释

　• 关键函数必须写上注释，说明函数的用途。
　• 特别函数参数，需要说明参数的目的，由谁负责释放等等。
　• 除了特别情况，注释写在代码之前，不要放到代码行之后。
　• 对每个#else或#endif给出行末注释。
　• 关键代码注释，包括但不限于：赋值，函数调用，表达式，分支等等。
　• 善未实现完整的代码，或者需要进一步优化的代码，应加上 // TODO …
　• 调试的代码，加上注释 // only for DEBUG
　• 需要引起关注的代码，加上注释 // NOTE …
　• 对于较大的代码块结尾，如for,while,do等，可加上 // end for|while|do

三、命名方面

１. 原则

　• 同一性：在编写一个子模块或派生类的时候，要遵循其基类或整体模块的命名风格，保持命名风格在整个模块中的同一性。
　• 标识符组成：标识符采用英文单词或其组合，应当直观且可以拼读，可望文知意，用词应当准确，避免用拼音命名。
　• 最小化长度 && 最大化信息量原则：在保持一个标识符意思明确的同时，应当尽量缩短其长度。
　• 避免过于相似：不要出现仅靠大小写区分的相似的标识符，例如"i"与"I"，"function"与"Function"等等。
　• 避免在不同级别的作用域中重名：程序中不要出现名字完全相同的局部变量和全局变量，尽管两者的作用域不同而不会发生语法错误，但容易使人误解。
　• 正确命名具有互斥意义的标识符：用正确的反义词组命名具有互斥意义的标识符，如："nMinValue" 和"nMaxValue"，"GetName()" 和"SetName()" ….
　• 避免名字中出现数字编号：尽量避免名字中出现数字编号，如Value1,Value2等，除非逻辑上的确需要编号。这是为了防止程序员偷懒，不肯为命名动脑筋而导致产生无意义的名字（因为用数字编号最省事）。

２. T,C,M,R类

　• T类表示简单数据类型，不对资源拥有控制权，在析构过程中没有释放资源动作。
　• C表示从CBase继承的类。该类不能从栈上定义变量，只能从堆上创建。
　• M表示接口类。
　• R是资源类，通常是系统固有类型。除了特殊情况，不应在开发代码中出现R类型。

３. 函数名

　• M类的函数名称应采用HandleXXX命名，例如：HandleTimerEvent；不推荐采用java风格，例如handleTimerEvent；除了标准c风格代码，不推荐用下划线，例如，handle_event。
　• Leave函数，用后缀L。
　• Leave函数，且进清除栈，用后缀LC。
　• Leave函数，且删除对象，用后缀LD。

４. 函数参数

　• 函数参数用a作为前缀。
　• 避免出现和匈牙利混合的命名规则如apBuffer名称。用aBuffer即可。
　• 函数参数比较多时，应考虑用结构代替。
　• 如果不能避免函数参数比较多，应在排版上可考虑每个参数占用一行，参数名竖向对齐。

５. 成员变量

　• 成员变量用m最为前缀。
　• 避免出现和匈牙利混合的命名规则如mpBuffer名称。用mBuffer即可。

６. 局部变量

　• 循环变量和简单变量采用简单小写字符串即可。例如，int i;
　• 指针变量用p打头，例如void* pBuffer;

７. 全局变量

　• 全局变量用g_最为前缀。

８. 类名

　• 类和对象名应是名词。
　• 实现行为的类成员函数名应是动词。
　• 类的存取和查询成员函数名应是名词或形容词。

９. 风格兼容性

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

四、代码风格方面

1. Tab和空格

　• 每一行开始处的缩进只能用Tab，不能用空格，输入内容之后统一用空格。除了最开始的缩进控制用Tab，其他部分为了对齐，需要使用空格进行缩进。这样可以避免在不同的编辑器下显示不对齐的情况。
　• 在代码行的结尾部分不能出现多余的空格。
　• 不要在"::","->","."前后加空格。
　• 不要在"，","；"之前加空格。

2. 类型定义和{

　• 类，结构，枚举，联合：大括号另起一行

3. 函数

　• 函数体的{需要新起一行，在{之前不能有缩进。
　• 除了特别情况，函数体内不能出现两个空行。
　• 除了特别情况，函数体内不能宏定义指令。
　• 在一个函数体内，逻揖上密切相关的语句之间不加空行，其它地方应加空行分隔。
　• 在头文件定义的inline函数，函数之间可以不用空行，推荐用一个空行。

4. 代码块

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

5. else

• if语句如果有else语句，用 } else { 编写为一行，不推荐用 3 行代码的方式。

6. 代码行

　• 一行代码只做一件事情，如只定义一个变量，或只写一条语句。这样的代码容易阅读，并且方便于写注释。
　• 多行变量定义，为了追求代码排版美观，可将变量竖向对齐。
　• 代码行最大长度宜控制在一定个字符以内，能在当前屏幕内全部可见为宜。

7. switch语句

　• case关键字应和switch对齐。
　• case子语句如果有变量，应用{}包含起来。
　• 如果有并列的类似的简单case语句，可考虑将case代码块写为一行代码。
　• 简单的case之间可不用空行，复杂的case之间应考虑用空行分割开。
　• case字语句的大括号另起一行，不要和case写到一行。
　• 为所有switch语句提供default分支。
　• 若某个case不需要break一定要加注释声明。

8. 循环

　• 空循环可用 for( ;; ) 或者 while( 1 ) 或者 while( true )

9. 类

　• 类继承应采用每个基类占据一行的方式。
　• 单继承可将基类放在类定义的同一行。如果用多行，则应用Tab缩进。
　• 多继承在基类比较多的情况下，应将基类分行，并采用Tab缩进对齐。
　• 重载基类虚函数，应在该组虚函数前写注释 // implement XXX
　• 友元声明放到类的末尾。

10. 宏

　• 不要用分号结束宏定义。
　• 函数宏的每个参数都要括起来。
　• 不带参数的宏函数也要定义成函数形式。

11. goto

　• 尽量不要用goto。

七、函数

１. 引用

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

２. 常量成员函数

　• 表示该函数只读取对象的内容，不会对对象进行修改。

３. 返回值

　• 除开void函数，构造函数，析构函数，其它函数必须要有返回值。
　• 当函数返回引用或指针时，用文字描述其有效期。

４. 内联函数

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

５. 函数参数

　• 只读取该参数的内容，不对其内容做修改，用常量引用。
　• 修改参数内容，或需要通过参数返回，用非常量应用。
　• 简单数据类型用传值方式。
　• 复杂数据类型用引用或指针方式。

其中，我以后想坚持的代码规范有：

1.空行

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

2.• 关键函数必须写上注释，说明函数的用途。

3.循环变量和简单变量采用简单小写字符串即可。例如，int i;
　• 指针变量用p打头，例如void* pBuffer;

4.• 一行代码只做一件事情，如只定义一个变量，或只写一条语句。这样的代码容易阅读，并且方便于写注释。

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

首先，我被作者用日常生活中的例子来解释复杂数学原理的巧妙手法所折服。这些看似平凡无奇的例子，如搜索引擎的工作原理、信息编码的效率等，在作者的笔下变得生动而有趣，让我深刻体会到数学并不是遥不可及的抽象概念，而是实实在在存在于我们生活的每一个角落，默默地为我们解决问题提供着强大的支持。
其次，第一章的内容让我深刻感受到了数学之美。这种美不仅仅体现在数学公式和定理的简洁与和谐上，更在于它们能够如此精准地描述世界的运行规律，解决人类面临的种种难题，通过作者的讲解，我意识到数学之美其实是一种实用之美，是一种能够激发人类创造力、推动社会进步的力量。
此外，这一章还让我对数学的学习态度发生了转变。以往，我或许会将数学视为一种枯燥无味的学科，需要不断地记忆公式和定理。但现在，我更加倾向于将数学视为一种探索世界、解决问题的工具，它需要我们用好奇心和创造力去发掘其中的奥秘，去体验数学带来的乐趣和成就感。

...全文