构建之法读书笔记 第4章 两人合作

代码规范

一个人独立完成的软件已经很少见了(向独立游戏开发者致敬)，软件都是在相互合作中完成的，最小单位: 俩人。

代码规范: 不同的人对代码好坏评判不同，需要基准

代码风格规范

• 文字上的规定，很重要

• 原则: 简明易读，无二义性

• 命名上应该一眼看出变量的类型和语义

  匈牙利命名法: 给变量以有意义的前缀。对于强类型的语言不必要

  Pascal: 所有单词首字母大写

  Camel: 第一个单词小写，其余单词遵循Pascal

  函数: 动词或者动宾来组合

• 注释

  复杂的注释应该放在函数头

  注释应该只用ASCII码

  误导的注释比没有注释更糟糕

  避免冗余的注释

代码设计规范

• 通用原则上的规范，牵涉模块关系等

• 函数

  只做一件事，并且做好

• goto

  函数最好有单一的出口，为达此目的，可以使用goto

  ？？以前都是听说要避免使用goto

• 错误处理

  验证参数正确性

  使用Assert

• 如何处理C++中的类

  • 类的使用

    使用类来封装面向对象的概念和多态

    指针传递，避免传递实体的值

    对于有显式构造和析构函数的类，避免建立全局的实体，因为不知道何时创建和消除

    仅在必要时使用类

    仅数据的封装，用struct即可

    仅在必要时使用类型继承

  • 关于数据成员和方法

    按照public, protected, private 的顺序来说明类中的成员

    使用虚函数来实现多态；仅在很有必要时使用虚函数；若一个类型要实现多态，在基类中的析构函数应该是虚函数(对于原因理解不是很清楚，是为了防止忘了在子类中写析构函数吗，对于c++不是很熟)

    数据成员 m_name; 不要使用公共的数据成员; 用inline访问函数，兼顾封装和效率

  • new和delete

    检查new的返回值，new不一定成功

    释放指针时不用检查NULL

  • 运算符

    不做标准语义之外的事情

    确实有必要时再定义

    需要高效

代码复审

• 代码是否在“代码规范”的框架里正确的解决了问题
• 自我复审、同伴复审、团队复审
• 目的
  • 找代码错误: 编码错误，不符合规范之处，逻辑和算法的错误，潜在的错误和回归星错误
  • 熟悉项目代码的途径
• 复审后
  • 更正明显的错误
  • 记录无法快速更正的错误
  • 记录自己常犯的错误，促进自我复审
• 代码复审的核查表(记下需要这个东西)

结对编程

Driver & Navigator

感觉有利于避免低级错误

这部分心理学，沟通技巧等

团队合作的重要性

笔记整理

• inline

  C++ 中，可以在定义函数时，在返回值类型前面加上 inline 关键字, 增加了 inline 关键字的函数称为“内联函数”。

  • 内联函数和普通函数的区别：当编译器处理调用内联函数的语句时，不会将该语句编译成函数调用的指令，而是直接将整个函数体的代码插人调用语句处，就像整个函数体在调用处被重写了一遍一样。
  • 不需要付出执行函数调用的额外开销
  • 内联函数中的代码应该只是很简单、执行很快的几条语句。否则失去意义了
  • 调用内联函数的语句前必须已经出现内联函数的定义（即整个数体），而不能只出现内联函数的声明。

inline int Max (int a, int b)
{
    if(a >b)
        return a;
    return b;
}

• 异常
  • 异常不能跨过DLL或进程的边界来传递信息，不太明白含义，还需要再了解
  • 异常处理机制及异常的花销
  • 不要用异常来作为逻辑控制来处理程序中的主要流程
  • 使用异常时注意在什么地方清理数据