在团队协作中，有很多个同学一起完成一个项目，良好的代码结构和代码规范能让团队协作更有效。
class Project {
···
}；
void getFileName();
float person_id;
#define _FOO_H_
const float E = 2.71从上面的代码中，通过命名我们能看出来，Project 是一个类，getFileName 是一个函数，person_id 是一个变量，E 是一个常量，仅仅通过命名我们就可以很好的区分各种不同类型。
- 这里的
class我们采用单词拼接的形式，每个单词的首字母大写。 - 函数也采用单词拼接的形式，第一个单词首字母小写，之后的单词首字母小写
- 变量采用
单词_单词的格式，每个单词小写，采用下划线连接，除此之外，驼峰命名法和匈牙利命名法也是非常常用的变量命名规范。 - 常量使用
const来定义，并且单词完全大写 - 宏定义保护使用
_PROJECT_MODULE_H_的形式来写
#ifndef _PROJECT_MODULE_H_
#define _PROJECT_MODULE_H_
...
#endif-
前言：代码可以不会写，但是人话一定要会说。在大家看懂你写的 bug 之前，请先学会写好一份人类可以正常快速看懂的
README。中英文都可以（吉祥物喜欢用英文）。在今后的团队中协作中，有一份良好的代码规范会帮助我们节约大量的沟通时间。 -
文档写在哪：除了在代码中添加注释之外，使用 Markdown 文件作为 README 文档是一个流行的选择。Markdown 是轻量型的标记语言，可以方便地将纯文本排版为像这篇文档一样的美观格式，推荐使用 GitHub Flavored Markdown 语法，更详细的内容可以参考这里。Markdown 文件使用
.md或.markdown后缀，可以放在 GitHub 代码区和 GitHub Wiki 里。 -
表头信息：表头信息非常重要，包含这个坑是谁最先挖的（作者/Author）、最后一位添加bug的人（修订/Revised）、最后一次修改的日期（日期/Date）、最新的更改（版本/Version）、展示一下您最新添加的bug（摘要/Abstract）。
## Title Here: Readme Tutorial - Author: Champion-Liu - Revised: Champion-Liu - Date: 2018-09-13 - Version: 1.0.0 - Abstract: Hello, this is the readme tutorial about how to show out your bug.
-
说明内容：包括模块怎么的功能是什么、接口是什么、需要哪些依赖库、怎么编译、测试程序怎么运行。
### Functions: ... //Brief is okay ### Interfaces: ... //C++ style declaration ### Depend Libraries: ... //should include origin websites
-
切记文档是用来看的！文档是用来看的！文档是用来看的！重点是简单清晰的说明代码用途。 接口示例：
/// Initialize the module static bool Hello::init(); /// Quit the module static void Hello::quit();依赖库示例：
常见的库，不需要说明安装方式 - 依赖opencv - 依赖pthread 不常见的库，一定要说明安装方式 - 依赖zbar 安装方式： 。。。。。。编译提示：
$ mkdir build $ cd build $ cmake .. -DGPU $ make -j$(nproc)测试程序：
# how to run: cd bin ./hello_test # the result if it is running well: >>> hello
对于独立的模块：
DigitsMerger(项目名)
|- inc/ (模块头文件)
|- src/ (模块源文件)
|- bin/ (编译后的模块测试执行文件)
|- test/ (模块测试的源文件)
|- readme.md (说明文档)
|- CMakeLists.txt (既作为项目子模块编译文件，又作为模块测试文件主编译文件)
- 如何 commit: 编译通过而且文档写完才可以 push 到 master 分支。
- 如何 merge：可以使用 GitKraken。
- 什么时候需要新分支：你自己挖坑的时候。
代码写得好不好，除了正确性，可读性和可维护性也是非常重要的一个评价指标。不管是团队项目中队友间互相debug，还是个人项目里自己的回溯修改，良好的代码风格都能带来极大的便利。还在担心看不懂自己前几天的代码？担心队友参与不了自己写的屎山？一起来养成规范的coding style吧！
具体的规范要以自己团队风格为主，融入团队才是最重要的。
我先来说说变量的命名。
主流有如下三种变量规则：
- 小驼峰、大驼峰命名法
- 下划线命名法
- 匈牙利命名法
小驼峰，第一个单词首字母小写，后面其他单词首字母大写。例如 int myAge;
大驼峰法把第一个单词的首字母也大写了。例如：int MyAge;
通常来讲 java和go都使用驼峰，C++的函数和结构体命名也是用大驼峰。
下划线命名法是名称中的每一个逻辑断点都用一个下划线来标记，例如：int my_age，下划线命名法是随着C语言的出现流行起来的，如果大家看过UNIX高级编程或者UNIX网络编程，就会发现大量使用这种命名方式。
匈牙利命名法是：变量名 = 属性 + 类型 + 对象描述，例如：int iMyAge，这种命名是一个来此匈牙利的程序员在微软内部推广起来，然后推广给了全世界的Windows开发人员。
这种命名方式在没有IDE的时代，可以很好的提醒开发人员遍历的意义，例如看到iMyAge，就知道它是一个int型的变量，而不用找它的定义，缺点是一旦该变量的属性，那么整个项目里这个变量名字都要改动，所以带来代码维护困难。
经常看到有的同学的代码都堆在一起，看起来都费劲，或者是有的间隔有空格，有的没有空格，很不统一，有的同学甚至为了让代码精简，把所有空格都省略掉了。
来看看Google C++的编程规范：
操作符左右一定有空格，例如
i = i + 1;
分隔符（, 和;）前一位没有空格，后一位保持空格，例如：
int i, j;
for (int fastIndex = 0; fastIndex < nums.size(); fastIndex++)
大括号和函数保持同一行，并有一个空格例如：
while (n) {
n--;
}
控制语句（while，if，for）前都有一个空格，例如：
while (n) {
if (k > 0) return 9;
n--;
}
这里关于大括号是否要重启一行？
Google规范是 大括号和 控制语句保持同一行的，我个人也很认可这种写法，因为可以缩短代码的行数，特别是项目中代码行数很多的情况下，这种写法是可以提高阅读代码的效率。
当然我并不是说一定要按照Google的规范来，代码风格其实统一就行，没有严格的说谁对谁错。