代码规范
一个人独立完成的软件已经很少见了(向独立游戏开发者致敬)，软件都是在相互合作中完成的，最小单位: 俩人。
代码规范: 不同的人对代码好坏评判不同，需要基准
代码风格规范
-
文字上的规定，很重要
-
原则: 简明易读，无二义性
-
命名上应该一眼看出变量的类型和语义
匈牙利命名法: 给变量以有意义的前缀。对于强类型的语言不必要
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或进程的边界来传递信息，不太明白含义，还需要再了解
- 异常处理机制及异常的花销
- 不要用异常来作为逻辑控制来处理程序中的主要流程
- 使用异常时注意在什么地方清理数据
