Introduction
arcs项目相关的规范文档，请在 arcs项目开发过程中务必遵守
文件夹的说明：
- bibliography: 一些参考文献及经典书籍
- code_style: 编码规范
- cubic: Ubuntu LiveCD发行版系统裁剪
- pics: 图片缓存
- scripts: 实用脚本
- styles: gitbook缓存
1 常见问题
1.1 不遵循编码规范
编码规范的精简版本是根据之前宣讲的编码规范的重点强制遵循的条款的简化版本，请参与开发的同事务必遵循，从项目的一开始养成好的习惯。
1.2 不遵循commit规范
目前的对commit的格式要求要求不是很严格，但起码的必须在commit信息中将commit的类型 type标准出来，commit信息将作为工程的历史信息一直存在，也需要我们从项目的一开始养成良好的习惯。commit信息在提交之后是可以更改的，详细的方法可以参考这里。
我们在修改commit信息之后push到远程时可能会失败，这时因为分支的历史被改变了，如果commit已经提交到自己的远程，但是还没有合并到主分支，可以在 git push之后加上 -f选项(前提是你自己的分支只有你自己提交代码，否则多人向同一分支提交代码的话会变得比较混乱)。
1.2 不遵循gitlab flow
gitlab flow是多人协作的规范，需要大家共同遵守。具体的流程可以仔细阅读文档
需要强调的一点是，在自己的分支开发完成之后，需要先将最新的主分支合并到自己的分支中来，这里要求使用 git rebase指令，这会工程的commit记录更加清晰，如果不是很熟悉 git rebase指令，可以仔细阅读这篇文档或者自行网上检索学习。
1.3 新的第三方库的引入
我们对第三方库的引入持慎重态度，主要是出于以下几个原因：
- 多人协作的项目，如果一人引入依赖，所有人必须同步依赖；
- 体量较大的第三方库会增加我们软件的体积；
- 我们一般只是在使用库，如果出现bug，维护成本比较高；
- 第三方库的引入不方便我们后期对代码性能的优化提升；
- 可能的license授权带来的法务风险；
- 对用户开放的API/SDK尽量不要依赖第三方库。
允许引入第三方库的情形：
- 稳定，并且社区或者开发者活跃；
- 体积较小，没有继承负担；
- 充分利用了该库的主要功能，而非仅仅是需要其个别特性（不如自己造轮子）；
- 临时追求开发速度的时候，这种情况之下要求不要直接依赖第三方库，最好是做一个封装层，便于以后的优化替换。
如果有必要引入第三方库，需要通过申请（可以在相关的repo下提issue，大家一起讨论）。
1.4 C++标准的选用
经过慎重考虑，个人认为还是采用C++11规范比较稳妥，理由如下： （1）我们有嵌入式交叉编译的需求，后期为了降成本或者缩小硬件体积，整个控制器系统很有可能会移植到嵌入式（ARM）平台之上 （2）对C++17的新特性需求并不是很大，基本上在C++11就可以满足我们现有的需求了 （3）迁移成本会比较大，首先我们现在软件开发人员基本都是从C转过来的，对C++11的特性目前来说也不是很了解，直接上C++17可能也不会能用好，甚至是适得其反 （4）另外，示教器软件的插件系统是对外的，如果采用C++17规范对于我们客户的要求也会提高
1.5 程序的错误/异常处理
对于错误，有三种处理策略。
- 修正重试
- 忽略
- 终止
（1）需要程序崩溃的错误
使用 assert。
一般来说，在控制器软件的内部如果软件/算法逻辑出了问题，我们会选择让整个程序崩溃（崩溃之前可以traceback），因为程序已经出现逻辑错误了，这些已经可以算作是软件bug了，返回错误值或者抛出异常都毫无意义。
- 控制逻辑的软件或者算法的输入参数错误；
（2）可以忽略的错误
使用错误代码系统（error_stack）。
- 机器人在运行过程中可能会出现“硬件错误”，软件可以生成错误代码（输出到日志系统）；
- 算法规划失败（输入的参数不合适）；
- 机器人运动安全违例（超出安全参数限制）。
（3）可以重试修正的错误
返回值。
直接在软件中进行重试处理（在调用函数中重试）。
- socket连接不成功；
- 关节通讯失败；
（4）异常
慎用。
仅允许在用户接口层使用C++异常机制，但是要在函数声明中明确注释。
- aubo_driver
- 示教器插件系统
除此之外的地方一律禁止使用C++异常。