第四章 两人合作

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.代码复审

   代码复审的形式

　　*复审的目的：找出代码的错误；发现逻辑错误；发现算法错误；发现潜在的错误

　　　　　　　　 和回归性错误；发现可能改进的地方；教育开发人员，传授经验

3.两人合作的不同阶段和技巧

　　　萌芽阶段 → 磨合阶段 → 规范阶段 → 创造阶段 → 解体阶段

　　　  如何正确给予反馈：

　　　　　　 —最外层：行为和后果

　　　　　　 —中间层：习惯和动机

　　　　　   —最内层：本质和固有属性

构建之法学习（第四章 两人合作）