公司组织架构编码规范文件 第1篇

头文件的相互包含的问题的原因 当编译出现XXX文件找不到的情况有可能是因为文件1包含了文件2，而文件2又包含了文件1，在编译解析的时候就会不断递归导致编译崩溃后，就找不到文件了

（1）当一个源文件过大的时候就应该考虑把一个源文件进行拆分。用一个更好一级的源文件include拆分的文件，整合调用

（2）一个源文件尽量仅仅使用一种编程语言，避免混编（不同编程语言的规范不太一样的）

所有头文件都应该使用#define 防止头文件被重复包含 .

1、所有继承必须是 public 的。 2、必要的话，析构函数声明为 virtual。如果你的类有虚函数，则析构函数也应该为虚函数 3、数据成员都必须是私有的，将所有数据成员声明为 private，除非是 static const 类型成员。 4、不要过度使用 protected 关键字。

当想要加入一点代码变得更加难，需要考虑到复杂的逻辑的时候就要重新梳理逻辑和工程架构了

（1）先有一个大方向架构目标，再从具体的每个小模块进行重构，重构一次不完美就重构第二次，修改格式绝对不可能一次完成的

（2）系统框架应该是最简单易懂的设计，若系统架构都是难以理解的逻辑，在该系统框架下的代码肯定是更加复杂的逻辑【大道至简】

一开始就不注重代码架构设计和规范，到最后面只会越走越难。即使是推倒重来也只能快跑一段时间跑不远的（无轨迹不成方圆）

（每段代码都应该出现在你设计的该有的位置上，如果该段代码不在这里，就应该重构代码，使得代码找到他该在的位置）

分task或者节点的原因 1、每个task的运行频率不一样 2、对模块之间进行解耦，开发逻辑更清晰

（1）了解并使用嵌入式系统平台的功能【os】 （2）导航系统各个模块的解偶，对每个模块层次进行重构 （3）对公共模块进行重构 （4）开始业务流程的重构

【公司的产品业务系统和ros的仿真验证系统的构建方式是不一样的】

. .

公司组织架构编码规范文件 第2篇

（1）在win下安装clang-format（或者安装一个总包LLVM），下载链接如下：

（2）在Linux下可以直接通过指令行安装，参考链接如下： . .

方法一：配置vscode的这一栏

方法二：直接在win中添加环境变量 win添加环境变量PATH的方法 .html

. .

第一个和第三个是设置标准的代码格式规范，当然也可以使用自己设置的格式规范（需要自己生成.clang-format格式文件），方法如下：

第二个是设置clang-format的环境变量位置（就是clang-format安装的位置）

第一个是设置保存文件时自动化进行格式化 第二个是设置自动格式化时时对整个文件进行格式化，还是仅仅对自己编写的代码进行修改

其他参考链接：

1、Clang_format已经被vscode集成了不需要再安装clang-format这个插件了 2、Clang是一个C语言、C++、Objective-C、C++语言的轻量级编译器，但是clang-format是代码格式化的工具

. .

公司组织架构编码规范文件 第3篇

（1）变量规范命名（针对词不达意的变量再命名）

（2）逻辑过于复杂，如if-else过多

（3）消除超大函数 一个好的函数必须满足单一职责原则，短小精悍，只做一件事

（4）整理类关系 多组合，少继承

（5）消除重复代码 法将它们合而为一，避免重复阅读

（6）消除无用代码（不要舍不得） 一种是没有使用场景，如果这类代码不是工具方法或工具类，而是一些无用的业务代码，那么就需要及时的删除清理。 另外一种是用注释符包裹的代码块，这些代码在被打上注释符号的时候就应该被删除【防盗标记–盒子君hzj】

（7）整理代码注释 无病呻吟，代码本身一眼就能看明白是在干什么，写代码的人非要在这个地方加一个不关痛痒的注释，这个注释完全是口水话，毫无价值可言

不合理的注释 注释是一把双刃剑，好的注释能够给我们好的指导，不好的注释只会将人误导

. .

对代码顶层架构进行重新设计，这类重构可能需要进行原则再定义、模式再定义甚至业务再定义

. .

（1）工作时自下到上，重构时从上至下，由外到内进行建模分析，理清各种关系，是重构的重中之重

（2）提炼类，复用函数，下沉核心能力，让模块职责清晰明了【防盗标记–盒子君hzj】

（3）依赖接口优于依赖抽象，依赖抽象优于依赖实现，类关系能用组合就不要继承

（4）类、接口、抽象接口设计时考虑范围限定符，哪些可以重写、哪些不能重写，泛型限定是否准确 . .

（1）重构太细致泛化能力差，容易出现无病呻吟的问题

（2）重构力度太小，效果不明显【防盗标记–盒子君hzj】

（3）重构到可以了解清楚方向和得到方法论就好 . .

公司组织架构编码规范文件 第4篇

（1）移植使用第三方代码需要根据我们的工程情况为第三方代码在封装一些函数接口，以保证代码的边界性

（2）看懂别人的代码，最好自己手撕一次！

（3）移植的心得，除非是算法小黑盒，不然移植还是要靠自己理解了去移植，因为业务和环境不一样 . .

（1）写代码和写论文是一样的，第一步先把内容写出来，第二步再封装整理使得格式和结构达到符合规范！

（2）打磨代码的方法：分解函数、修改名称、消除重复、重新设置架构、抽象成类同时保证测试通过。

都是需要时间一关一关的过的！

不同代码的测试方法不一样，只要可以通过测试的最后一关就说明生产代码是符合标准的！ （1）方法一：使用文字和指令告诉测试工程师测试方法，让可是工程师在不同场景做测试 （2）方法二：把指令封装到bash文件中，一键启动 （3）方法三：自己根据测试场景和需求去边测试用例 . .

公司组织架构编码规范文件 第5篇

代码整洁的排版需要一套简单的格式规则 （0）代码的空格和缩进要有规范

（1）注意在一行代码中代码不宜过长–使用分隔符(甚至可以直接换行)

（2）注意作用域的缩进格式–使用标准的TEB键

（3）注意代码行和代码行之间不能有空行，函数与函数之间空一行就行

（4）注意判断与赋值符号两边都要留有空格，空格字符有强调的作用

（5）函数的形参一般在括号出不留空格，在逗号后面加一个空格，强调变量的数量

（6）变量定义在符合作用域的前提下，尽量与调用位置靠近，不必集中的定义在一个地方（全局变量定义在使用它的函数前面）

（7）函数在头文件声明的位置

相关概念的函数声明应该放在一起，甚至定义成一个类。函数的共性越强，当的距离应该更近一些

（6）类和枚举的一些变量垂直应该对齐，缩进适当 （9）在while、for、if这些语句后的大括号要留下一个{，if/else相互嵌套时，if else不能分开，不然条件嵌套关系不明显

（10）如果while、for这些语句的循环是空的也要用大括号{}，尽量不要只写一个分号，迷惑性极强

对象和数据结构的格式 （1）类内public的成员是别人可以用的 （2）类内privide是自己用的 （3）类内函数和类内变量要分开写，宁可多写几个public和privide的关键字 （4）类的内容应该尽可能小，类是同一性质成员的最小单元。类与类之间可以继承和友元使用，代码越长越难理解 （5）抽象出来同一层次的类，同一层次的类使用工厂设计模式！提供标准的参考模板

公司组织架构编码规范文件 第6篇

仅当只有数据成员时使用 struct，其它一概使用 class。

同一作用范围和层次的变量或者函数要抽象成结构体和类

变量尽量不要定义成全局变量，如果不得已要定义成全局变量，也要把一类的全局变量封装到一个类中，实例化一个类从而定义一个全局变量，最好还要给该类修饰一个作用域namespace . .

尽可能使用智能指针，避免内存泄露。倾向于使用 std::unique_ptr 明确所有权传递。如果要使 用共享所有权，建议使用 std::shared_ptr。不要使用 std::auto_ptr，使用 std::unique_ptr 代替它。 . .

auto 关键字可以自动匹配变量和函数的数据类型，用 auto 绕过烦琐的类型名，只要可读性好就继续用，别用在局部变量之外的地方。

使用 C++ 的类型转换，如 static_cast<>()。不要使用 int y = (int)x 或 int y = int(x)等转换方式。

整数用 0，实数用 ，指针用 nullptr(C++ 11)，字符 (串) 用 ‘\0’。

. .

公司组织架构编码规范文件 第7篇

一个函数只做一件事情，把函数设计成实现一个最小功能的单元就好，只做一件小事情，多个小事情组合成为一个大事情。 .

（1）一个函数代码量尽量在30行左右为佳。函数越长阅读起来越费劲，迁移和组合难度越大！功能越死板改动一下功能都更难。如果函数超过30 行，可以思索一下能不能在不影响程序结构的前提下对其进行分割。

（2）各个函数是嵌套关系的，因为阅读代码一般是自顶向下阅读的，因此每个函数都要归为一类，一般分为：底层的实现函数、中间层的逻辑组合函数、顶层的业务功能函数三类，进行函数的组合。

1、函数的参数顺序 输入参数在先，后跟输出参数。

2、输入参数若是在函数中不可改变的，尽可能使用关键字const修饰 const 关键字为数据成员在编译时类型检测增加了一层保障; 便于尽早发现错误。如果函数不会修改你传入的引用或指针类型参数，该参数应声明为const。 如一般输入的变量在函数中不能被改变的（如定位的pose）必须用const进行修饰。

3、输出参数要么使用指针“*”、要么使用引用“&”，后者更佳 输出参数可以使用引用“&”和指针“*”

4、函数的返回数据类型 bool类型或者枚举类型的输出用函数类型进行return，这样做那一条函数出现问题可以快速定位.一般的函数尽量不要定义成void类型的，至少定义成一个bool类型的，或者是枚举errorcode类型的。没有返回值的函数挂了也检测不出来。

6、初始化列表的方法 若传入对象比较复杂，可以传入参数列表，本质还是用一个更大的数据接口包含一系列小的变量

7、工厂函数的接口 定义类的虚函数，甚至是纯虚函数。

若函数太长，或者函数有较多重复的函数调用，这时候就要考虑函数的封装了使得函数更加能够理解读懂，使得代码不要那么臃肿，同时保证代码短小精简

串联逻辑用if/else，并联逻辑用switch/case . .

只有当函数只有 10 行甚至更少时才将其定义为内联函数。通常内联函数不包含循环、switch 语句，且不是递归函数。

（1）一般函数的输出一定要有接口，函数不依赖任何全局变量（不要在外面定义一个全局变量，在函数内使用全局变量达到参数传递的效果） （2）若是输入或者输出的参数较多，且参数都属于一类的数据，可以定义一个类，并用这个类实例化一个对象，把对象作为参数传进去函数。函数就可以访问对象里面的所有成员。 （3）尽量编写一元函数和二元函数，传入传出参数过多调用函数设置的时候就复杂，同时函数头也比较长不美观（传入对象而非一个参数变量能解决这个问题） （4）区分输入参数和输出参数的直观方法：输出参数一般用const甚至没有修饰，输出参数用引用&和指针*进行标志 （5）若一行代码过长，或者函数传入的参数过多，为了格式对齐要用分隔符“/”进行隔断

. .

公司组织架构编码规范文件 第8篇

（1）自己梳理现有架构 对涉及重构部分的现有业务、架构进行梳理，明确重构的内容在系统的哪个服务层级、属于哪个业务模块，依赖方和被依赖方有哪些，有哪些业务场景，每个场景的数据输入输出是怎样的

（2）会议明确重构的内容、方向目标 满足未来的方向，且方向是经得起大家的质疑

（3）会议宣讲，项目立项 重构涉及到哪些业务和场景、大概的重构方式、业务影响可能有哪些，难点及可能在哪些步骤出现瓶颈 周知大概的时间计划表（粗略的大致时间）【防盗标记–盒子君hzj】 明确各组主要负责的人

（1）会议架构设计与评审

（2）分工进行代码的编写、测试、线下实施

【公开】开一个重构复盘会 （1）检查每个参与方是否都达到了重构要求的标准【防盗标记–盒子君hzj】 （2）复盘重构期间遇到的问题、以及解决方案是什么样的 （3）沉淀方法论避免后续的工作出现类似的问题。

. 【个人】沉淀项目部署经验

（1）业务架构 （2）系统技术模块架构【依赖？】 （3）源码输入输出数据流架构 （4）相关的设计图和文档

还有经常看的那基本代码整洁之道、代码重构的几本书

公司组织架构编码规范文件 第9篇

如果我纯粹为今天工作，明天我将完全无法工作，但其实大多数人都是不喜欢重构工作的，就像没有人愿意给别人“擦屁股”一样【防盗标记–盒子君hzj】 .

不知道怎么重构，缺乏重构的经验和方法论 .

重构需要你付出额外的工作去读懂别人的程序【学习还行】，重构会破坏现有程序，带来意想不到的Bug，不想去承受这些意料之外的Bug。【防盗标记–盒子君hzj】 .

很难看到短期收益，无法产出新的功能，业务上没有任何推进，长远看来，说不定当项目收获这些利益时，你已经不负责这块工作了

. .

公司组织架构编码规范文件 第10篇

在try/catch中尽量不要有太多的代码，最好再进行一次函数封装，使得try/catch的结构更加清晰，示例如下：

这个需要函数是errorcode的数据类型的，一般返回错误代码是用于调试输出的（看log），使用异常事件是用于系统底层做出对应动作的（看warning和error的系统信息）。程度不一样。 一般有一个的文件对应 Errorcode的方式 . .

公司组织架构编码规范文件 第11篇

（1）可以理解的前提下，尽可能少的注释。 （2）有多余的注释测试完成，功能可用后要及时整理删除更新。

（1）在调试代码的时候可以写下注释，再通过测试后应该删除注释，并把原来的注释翻译简化留下基本的提醒就好。 （2）注释本质是一个提醒，边测试边修改，验证错误的注释必须马上删除 （3）注释是写程序的中间产物，程序员是不会维护注释的，注释停留的时间越长信息描述越不准确（程序在变化，注释也要跟着变化）

1、使用一看就懂的变量和函数命名方式，一写出来的代码就知道这个函数变量的意思

2、尽量不要去写注释的方向去想

3、代码在测试阶段还有价值就先别删掉，测试完毕没有价值的代码或者是就方案的代码就可以删除掉了，甚至定义的函数但没有被调用的函数一样可以被删除掉。

. .

公司组织架构编码规范文件 第12篇

常量参数优先用宏定义，出现数字是很难被理解的，一些需要进行调节的参数必须定义为#define的形式，不然不直观，甚至很难进行更改！

宏的命名单词全部大写，由下划线连接

命名时以“k”开头，大小写混合

命名的首要原则是名副其实，每个命名都要力求有意义且简洁，函数的命名一般使用动名词。变量的的命名一般使用名词，变量（包括函数参数）和数据成员名一律小写，单词之间用下划线连接。

全局变量后加下划线，局部变量后不加下划线

类名和对象名应该是名词或者名词短语，且开头大写，多名词组合的独立名词首字母也要大写，不包含下划线，如

函数名（方法名）应该是动词或者动名词，且开头动词小写，动词与名词组合的名词大写，单词之间不使用下划线。

文件名要全部小写，以下划线”_”连接不同单词。不要使用已经存在与/usr/include 下的文件名。 . .

公司组织架构编码规范文件 第13篇

Launch文件最好放在一个功能包里面，用命令行容易寻找得到，同时编程的时候工程也不用这么乱。总的launch文件搞一个robot_launch功能包，子功能包内放一个launch文件夹来存放【防盗标记–盒子君hzj】

注意 （1）功能包是多个文件夹的东西一起写的，不分先后顺序，同时进行debug【防盗标记–盒子君hzj】

（2）不同的功能包可以定义相同名字的变量和函数，因为功能包名字不一样，所以不同的功能包可以定义相同名字的变量和函数，这样可以使得功能包更加连贯起来，同时功能又相互独立

（1）#include<功能包名/.h文件名>

（2）.cpp构造函数编写最好是有顺序规范的 【构造函数最好带有句柄，.h文件的class也是对应这个顺序】

（3）.h的类：对应写声明，分门别类

注意 没有写完main()函数就会报错，因为编译找不到起点，要写完main()函数，类和构造函数逗得先写完【防盗标记–盒子君hzj】

待补充~

（1）在节点node中设置订阅和发布topic名字的技巧

（2）话题名规范，话题名前面都加上“/”，作为话题的识别【当然不加也可以】【防盗标记–盒子君hzj】

. .