第四章 两人合作
1.代码规范
1）代码风格规范。主要是文字上的规定，看似表面文章，实际上非常重要。
*原则：简明，易读，无二义性
*缩进：4个空格
*行宽：行宽必须限制，可以限定为100字符
*括号：在复杂的条件表达式中，用括号清除地表示逻辑优先级
*断行与空白的{}行：推荐格式如下
if ( condition )
{
DoSomething();
}
else
{
DoSomethingElse();
}
*分行：不要把多条语句放在一行上。并且，不要把多个变量定义在一行上
*命名：例如 “匈牙利命名法”
*下划线：下划线用来分隔变量名字中的作用域标注和变量的语义
*大小写：
Pascal——所有单词的第一个字母都大写
Camel——第一个单词全部小写，随后单词随Pas-cal形式，这种方式也
叫lowerCamel
一个通用的做法是：
-
-
-
- 所有的类型/类/函数名都用Pascal形式，所有的变量都用Camel形式
- 类/类型/变量：名词或组合名词，如Member、ProductInfo等
- 函数则用动词或动宾组合词来表示，如get/set、RenderPage()
-
-
*注释：
—复杂的注释应该放在函数头，很多函数头的注释都用来解释参数的类型
等，如果程序正文已经能够说明参数的类型in/out，就不要重复！
—注释也要随着程序的修改而不断更新，一个误导的（Misleading）注释
往往比没有注释更糟糕 。
—另外，注释（包括所有源代码）应该只用ASCII字符，不要用中文或其
他特殊字符，否则会极大地影响程序的可移植性。
—在现代编程环境中，程序编辑器可以设置各种美观得体的字体，我们可
以使用不同的显示风格来表示程序的不同部分。
2）代码设计规范。牵涉到程序设计、模块之间的关系、设计模式等方方面面的通则。
*函数：最重要的原则是：只做一件事，并且要做好
*goto:函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程
序逻辑的清晰体现，什么方法都可以使用，包括goto
*错误处理：
—参数处理（在Debug版本中，所有的参数都要验证其正确性。在正式版本
中，对从外部（用户或别的模块）传递过来的参数，要验证其正确性。）
—断言（当你觉得某事肯定如何时，就可以用断言验证正确性。如果你认为
某事可能会发生，这时就要写代码来处理可能发生的错误情况。）
* 如何处理C++中的类
—使用类来封装面向对象的概念和多态
—避免传递类型实体的值，应该用指针传递。换句话说，对于简单的数据类型，
没有必要用类来实现
—对于有显式的构造和析构函数的类，不要建立全局的实体，因为你不知道它
何时创建和消除
—仅在必要时，才使用“类”
2.代码复审
代码复审的形式
| 名称 |
形式 |
目的 |
| 自我复审 |
自己 vs 自己 |
用同伴复审的标准来要求自己。不一定最有效，因为开发者对 自己总是过于自信。如果能持之以恒，则对个人有很大好处 |
| 同伴复审 |
复审者 vs 开发者 |
简便易行 |
| 团队复审 |
团队 vs 开发者 |
有比较严格的规定和流程，适用于关键的代码，以及复审后不 再更新的代码覆盖率高——很多双眼睛盯着程序，但效率可能 不高（全体人员都要到会） |
*复审的目的：找出代码的错误；发现逻辑错误；发现算法错误；发现潜在的错误
和回归性错误；发现可能改进的地方；教育开发人员，传授经验
3.两人合作的不同阶段和技巧
萌芽阶段 → 磨合阶段 → 规范阶段 → 创造阶段 → 解体阶段
如何正确给予反馈：
—最外层：行为和后果
—中间层：习惯和动机
—最内层：本质和固有属性