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