编码规范合入

klc407073648 · klc407073648 · commit 3ff7b4867053 · 2023-03-08T22:31:55.000+08:00
diff --git a/md/method/code-style/code-style-code-style.md b/md/method/code-style/code-style-code-style.md
@@ -0,0 +1,67 @@
+# 编码规范 - 编程风格
+
+# 类成员函数声明，需要与定义分开。
+
+* 不要直接将类函数定义写在头文件中，一是暴露具体实现，而是导致头文件内容过大。
+
+备注：模板或内联函数或简单逻辑除外
+
+# 禁止接口有多个返回值，需采用闭包、访问者模式实现
+
+```cpp
+void queryPathAndResult(string& path,string& res)
+```
+
+# 类的声明格式
+
+```cpp
+class Test{
+    //公有函数
+    public:
+
+    //私有函数
+    private:
+
+    //保护成员
+    protected:
+
+    //私有成员
+    private:
+
+}
+
+```
+
+# 类成员，不超过10个
+
+* Clean Code 角度
+
+# 类方法，不超过30个
+
+* Clean Code 角度
+
+# 不将成员变量，直接作为接口参数
+
+* 不规范
+
+# 宏定义禁止包含复杂判断，以规避复杂度检查
+
+* 避免引入错误
+
+# 非冒号表达式的循环，固定上界保护
+
+```cpp
+//正例
+for(int i=0;i<maxNum;i++){
+    ...
+}
+
+// 反例,无限制导致死循环
+for(int i=0; ;i++){
+    ...
+}
+```
+
+# list容器禁止使用size方法，如果需要用其它容器替换
+
+* list容器的size方法是遍历得到大小，O(N)复杂度
diff --git a/md/method/code-style/code-style-google-c++.md b/md/method/code-style/code-style-google-c++.md
@@ -1,4 +1,4 @@
-# Google C++ Style Guide
+# 编码规范 - Google C++ Style Guide
 
 [[toc]]
 
diff --git a/md/method/code-style/code-style-head-file.md b/md/method/code-style/code-style-head-file.md
@@ -0,0 +1,137 @@
+# 编码规范 - 头文件包含规范
+
+[[toc]]
+
+# C/C++头文件包含规范
+
+## Self-contained 头文件自包含
+
+* 所有头文件要能够自给自足，即头文件需要包含**本身依赖**的其他头文件。
+* 换言之，用户和重构工具不需要为特别场合而包含额外的头文件。
+
+## 头文件中尽量减少对其他头文件的依赖
+
+* 头文件包含另一个头文件的同时会引入一项新的依赖(dependency)，这个依赖也会随着该头文件的被包含而扩散出去，从而导致**依赖扩散**。
+
+* 只要头文件被修改，代码就要重新编译，如果你的头文件包含了其它头文件，**这些头文件的任何改动都将导致那些包含了你的头文件的代码重新编译**。
+
+### 多余的头文件包含
+
+* 头文件包含必须遵循最少必要原则，尽量少包含。
+* 能包含小的头文件，不包含大的头文件。
+* 及时清理不需要的头文件包含，不能只增不删。
+
+### 可以在source文件包含的，不要包含着头文件中
+
+例如，Test.h头文件以及对应Test.cpp文件。
+
+Test.h只要包含改头文件所依赖的其他头文件，不能将Test.cpp所需要用到的头文件全都放在Test.h中。
+
+### 头文件仅声明，不作实现
+
+如果头文件里包含函数实现，在其他多个源文件中使用include方式包含时，会提示多重定义(multiple definition)
+
+### 头文件是只包含必要的声明
+
+* 不是所有函数实现都需要在头文件中声明，只声明需要发布的函数接口。
+
+* 私有函数不在头文件中声明，从而减少头文件的依赖。例如，某些工具类方法可以声明和实现在.cpp函数的类外。
+
+### define 保护
+
+* 所有头文件都应该使用 #define 来防止头文件被多重包含, 命名格式例如: 
+
+```cpp
+#ifndef Data_MySQL_MySQLException_INCLUDED
+#define Data_MySQL_MySQLException_INCLUDED
+```
+
+### 使用前置声明(forward declarations)
+
+* 「前置声明」（forward declaration）是类、函数和模板的纯粹声明，没伴随着其定义. 
+
+看法一：
+
+* 尽可能地避免使用前置声明。使用 #include 包含需要的头文件即可。 
+* 前置声明隐藏了依赖关系，头文件改动时，用户的代码会跳过必要的重新编译过程。
+
+看法二：
+
+* 通过前置声明的方式，减少头文件中依赖的其他头文件。将头文件的包含动作延迟到源文件中去实现。
+
+* 使用场景：头文件只用到对应内容的指针或引用不涉及具体内容。或用到一个结构体声明，但不想包一个很大的头文件将依赖扩散。（struct Foo;在源文件中#include <Foo.h>）
+
+可以参考：[C++前置声明](/md/c++/tips/c++-tips-forward-declaration.md)
+
+## 避免错误依赖和反向依赖
+
+* 包含每个头文件时，需要分析是不是合适的依赖，避免包含错误的头文件，导致其依赖的其他头文件项变多。
+
+```cpp
+//log.h
+
+#include<logType.h>
+#include<logTime.h>
+
+//不应该包含项
+#include<message.h>
+#include<httpType.h>
+```
+
+## 尽可能将代码拆分成相对独立的，粒度小的单元，放到不同的文件中
+
+* 不能使得一个类代码很臃肿，包含特别多的功能，不方便维护。
+
+* 通过拆分成小的，独立的模块更利于维护。
+
+## 包含头文件顺序
+
+头文件Test.h和源文件Test.cpp，对应的头文件包含顺序都需要满足：
+
+1. Test.h （如果自己定义的头文件有错，编译时会提前暴露自身的错误而不是其他库的。）
+2. 本项目内的.h文件
+3. 其它库的.h文件
+4. C系统文件
+5. C++系统文件
+
+没有唯一的标准，都是适合自己的习惯，google C++ 头文件顺序：
+
+1. 主体功能文件（这一条规则保证维护这些文件的人们首先看到构建中止的消息而不是维护其他包的人们。）
+2. C系统文件
+3. C++系统文件
+4. 其它库的.h文件
+5. 本项目内的.h文件
+
+## 包含头文件时，使用源码的目录树结构，不使用相对路径
+
+使用源码的目录树结构，而不是相对路径：
+
+* 为保证唯一性, 头文件的命名应该基于所在项目源代码树的全路径
+
+* #include <drogon/orm/Result.h>  √
+* #include <../../Result.h>       ×
+
+## 头文件中不允许使用using namespace XXX·措施
+
+* 头文件使用 `using namespace XXX` 会破坏 namespace 的封装性
+* 因为头文件会被包含在其他的头文件和cpp文件中。导致C++编译器将头文件字符串直接拷贝，强制其他的头文件也使用 `using namespace XXX`,从而引起编译错误，或者使用错误的类型，造成麻烦。
+
+```cpp
+//正例
+namespace HttpProxy{
+    using Poco::ByteOrder;
+    using Poco::UInt16;
+}
+
+// 反例
+
+namespace HttpProxy{
+    using namespace Poco;
+}
+```
+
+
+# 保证措施
+
+* 代码扫描工具识别多余包含
+* Code Review发现头文件包含是否规范
diff --git a/md/method/code-style/code-style-naming-rule.md b/md/method/code-style/code-style-naming-rule.md
@@ -0,0 +1,122 @@
+# 编码规范 - 常用编码命名规则
+
+
+[[toc]]
+
+# 驼峰命名法
+
+> 最常见的一个命名法，命名方式使用大小写混合的格式来区别各个单词，并且单词之间不使用空格隔开或者连接字符连接的命名方式。
+
+## 大驼峰命名法（CamelCase）
+
+**通常类名需要使用大驼峰命名法**
+
+```cpp
+//正例：
+ServiceDiscovery、ServiceInstance、LruCacheFactory
+//反例：
+serviceDiscovery、Serviceinstance、LRUCacheFactory
+```
+
+## 小驼峰命名法（lowerCamelCase）
+
+**通常函数方法名、参数名、成员变量、局部变量需要使用小驼峰命名法**
+
+```cpp
+//正例：
+getUserInfo()、createCustomThreadPool()、setNameFormat(String nameFormat)
+Uservice userService;
+
+//反例：
+GetUserInfo()、CreateCustomThreadPool()、setNameFormat(String NameFormat)
+Uservice user_service
+```
+
+# 蛇形命名法（snake_case）
+
+**通常测试方法名、常量、枚举名称需要使用蛇形命名法。**
+
+在蛇形命名法中，各个单词之间通过下划线“_”连接，比如
+
+`should_get_200_status_code_when_request_is_valid、CLIENT_CONNECT_SERVER_FAILURE`
+
+蛇形命名法的优势是命名所需要的单词比较多的时候，比上面通过小驼峰命名法得到的名称易读：
+
+`shouldGet200StatusCodoWhenRequestIsValid`
+
+```cpp
+//正例：
+@Test
+void should_get_200_status_code_when_request_is_valid() {
+  ......
+}
+
+//反例：
+
+@Test
+void shouldGet200StatusCodoWhenRequestIsValid() {
+  ......
+}
+```
+
+# 串式命名法（kebab-case）
+
+在串式命名法中，各个单词之间通过下划线“-”连接
+
+**建议项目文件夹名称使用串式命名法**
+
+在Vue中，定义组件名
+
+* kebab-case（短横线命名）
+  * `Vue.component('my-component-name', { /* ... */ })`
+
+* 使用 大驼峰命令（CamelCase）
+  * `Vue.component('MyComponentName', { /* ... */ })`
+
+# 匈牙利命名法（Hungarian）
+
+hwnd：h 是类型描述，表示句柄， wnd 是变量对象描述，表示窗口，所以 hwnd 表示窗口句柄。
+pfnEatApple：pfn 是类型描述，表示指向函数的指针， EatApple 是变量对象描述，所以它表示指向 EatApple 函数的函数指针变量。
+g_cch：g_ 是属性描述，表示全局变量，c 和 ch 分别是计数类型和字符类型，一起表示变量类型，这里忽略了对象描述，所以它表示一个对字符进行计数的全局变量。
+
+**匈牙利命名法基本原则：变量名=属性+类型+对象描述**
+
+* 全局变量用g_开头,如一个全局的长型变量定义为g_lFailCount
+* 静态变量用s_开头,如一个静态的指针变量定义为s_plPerv_Inst
+* 成员变量用m_开头,如一个长型成员变量定义为m_lCount
+* 局部变量用l_开头,如一个整型局部变量定义为l_inum
+
+```
+属性部分：
+g_ 全局变量
+c_ 　常量
+m_ 　c++类成员变量
+s_ 　静态变量
+类型部分：
+数组 a
+指针　p
+函数　fn
+无效　v
+句柄　h
+长整型　l
+布尔　b
+浮点型（有时也指文件）　f
+双字 　dw
+字符串　 sz
+短整型　 n
+双精度浮点　d
+计数　c（通常用cnt）
+字符　ch（通常用c）
+整型　i（通常用n）
+字节　by
+字　w
+实型　r
+无符号　u
+描述部分：
+最大　Max
+最小　Min
+初始化　Init
+临时变量　T（或Temp）
+源对象　Src
+目的对象　Dest
+```
diff --git a/md/method/code-style/code-style-naming-specification.md b/md/method/code-style/code-style-naming-specification.md

Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-# Google C++ Style Guide`
	`1`	`+# 编码规范 - Google C++ Style Guide`
`2`	`2`
`3`	`3`	`[[toc]]`
`4`	`4`