架构设计
- 保证抽象层次性一致。
- 对于非常大型的项目来说,物理设计是项目成功的决定性因素。
- 软件架构,很重要的一条就是open-close原则,要清楚哪些是可变的哪些是不可变的。
- 面向對象本身只解決了“結構”和“編程方法”的問題,而並沒有對“流程”加以改造。
编程语言
- 语言只是软件开发的一环而已,单凭语言并不能应付业务和工程上的问题。
- 语言方面,若已掌握了了C/Java,那么C++/Python/Bash/Javascript等都应该了解一下概念,至少要理解在一个完整的产品链里,它们分别适用于哪个环节。
构建与运行
- 重用别人的包时,将build下的内容清空,因其中可能包含有机器相关的信息,如路径信息等,这些信息将导致编译无法通过。
- 当编译器给出的错误信息涉及“.cpp”、“.h”文件时,有可能是头文件路径配置有误,当错误信息涉及“linker”、“.obj”、“.lib”时,则往往可能是库文件路径或依赖输入项配置有误。
- 头文件是和编译器无关的;而库文件及可执行文件是和编译器相关的。
- 使用编译器的最高警告级别。
编码风格
- 头文件集中存放,而不要分散开来。
- 除std名字空间外,其他名字空间一律不打开。
- 头文件的名字都是类名。
- 与所维护文件中已有的体例保持一致。
- 全大写字母表示宏。
- 不用Tab,用若干空格,如4个空格,以表示缩进。
- 取函数地址的时候,显示地使用&运算符。
- 不在注释中重复写代码语义,因为这会造成不一致。应该写的是解释方法和原理的说明性注释。
- 消除代码中所有的字面值。禁止任何的写死操作。ROS系统是“把代码写活的生动例子”。
- 当工程规模逐渐增大时,文件的规范命名就是重要的。
- 完全封装好的类没有公有数据。从逻辑角度来看,数据成员只是类的实现细节。
- 不要写自己都不想读的代码。
- 请从作为代码提供者的角度体谅代码作者:
1.编译配置文件的书写是机器相关的,需要使用者主动修改;
2.注释大多为自注释,这是人之常情。 - 後台的計算應一貫地採用標準單位,否則後患無窮。只有需向用戶顯示信息時,才採用非標準單位的數據。
- 每个函数须经过彻底的测试方可投入使用。
- “好”的函数的一个特征是,既有入口参数,又有出口参数,返回值则是一个状态标签,用于表征函数的执行状态。
- 建立自己的程序工具箱,是一个提升效率的不错选择。
- 能用加法的不用乘法,尽量避免浮点数的除法运算,因为浮点数的除法运算非常慢。
- 力争把程序写活。例如,从文本读取参数就不需要重新编译程序,这个体验很好。
- 編寫軟件系統時,各個模塊要高內聚低耦合。一个文件包含不必要的頭文件,是造成C++中過多耦合的常見原因。
- 当需要传递给函数一个大对象的时候,千万不能传一个对象,而要传址(要么用指针,要么用引用)。不要说这样的内存开销非常巨大,就算开销不大,也禁止使用,因为运行错误可能在所难免。
- 不要混合使用绝对路径和相对路径。
数据结构
- 關聯容器一般是用二叉樹實現的。其元素默認已按升序排好序。
例如,set的插入方法時間複雜度是O(log(n))。
算法设计
- 掌握住循环就掌握住了程序的生命。
而掌握循环的关键是当循环嵌套时,分步写内层循环,并归纳出外层循环的规律。接着,对其正确性进行全方位测试。
这玩意儿有点可意会不可言传的赶脚。
并发设计
- Linux平台下创建多个进程比较容易实现。Windows下就比较困难。两个经典的案例是:ROS和對管道操作的天然支持。
在Windows环境下,尽量用多线程而不是多进程。 - 线程安全的设计方法:RAII 。
- 参考链接:https://solarianprogrammer.com/2011/12/16/cpp-11-thread-tutorial/
It is the programmer’s job to ensure that a group of threads won’t block trying to modify the same data.
实用工具
- 做代碼維護時,beyond compare和Meld Diff是必不可少的工具。