构建之法阅读笔记02

              第4章 两人合作

4.1 代码规范

计算机只关心编译生成的机器码,你的程序采用哪种缩进风格,变量名有无统一规范等,与机器码的执行无关。但是,做一个有商业价值的项目,或者在团队里工作,代码规范相当重要。

 

“代码规范”可以分成两部分:

         1.代码风格规范。主要是文字上的规定,看似表面文章,实际上非常重要。

         2.代码设计规范。牵涉到程序设计、模块之间的关系、设计模式等方方面面的通则。

4.2 代码风格规范

4.2.1 缩进

最好用4个空格。

4.2.2 行宽

行宽必须限制,可以限定为100字符。

4.2.3 括号

在复杂的条件表达式中,用括号清除地表示逻辑优先级。

4.2.4 断行与空白的{}行

这里作者推荐每个“{”和“}”都独占一行。

在这里,我还是采用Linux中的风格,除了函数和类。

if ( condition ) {

   DoSomething();

} else {

DoSomethingElse();

}

4.2.5 分行

不要把多条语句放在一行上。并且,不要把多个变量定义在一行上。

4.2.6 命名

详见下面大小写。

4.2.7 下划线

一般不用。

4.2.8 大小写

Pascal —— 所有单词的第一个字母都大写。

Camel —— 第一个单词全部小写,随后单词随Pascal形式。

所有的类型/类/函数名都用Pascal形式,所有的变量都用Camel形式。

函数中get/set中例外。

4.2.9 注释

不要注释程序是怎么工作的(How),程序本身就应该能说明这一问题。

注释是为了解释程序做什么(What),为什么这样做(Why),以及要特别注意的地方。

复杂的注释应该放在函数头,很多函数头的注释都用来解释参数的类型等,如果程序正文已经能够说明参数的类型in/out,就不要重复!

注释要随着程序的修改而不断更新,一个误导(Misleading)注释往往比没有注释更糟糕。

4.3 代码设计规范

代码设计规范不光是程序书写的格式问题,而且牵涉到程序设计、模块之间的关系、设计模式等方方面面。

4.3.1 函数

现代程序设计语言中的绝大部分功能,都在程序的函数(Function、Method)中实现。关于函数,最重要的原则是:只做一件事,并且要做好。

4.3.2 goto

函数最好有单一的出口,为了达到这一目的,可以使用goto。只要有助于程序逻辑的清晰体现,什么方法都可以使用,包括goto。

4.3.3 错误处理

当程序的主要功能实现后,一些程序员会乐观地估计只需要另外20%的时间,给代码加一些错误处理就大功告成了,但是这20%的工作往往需要全部项目80%的时间。

1. 参数处理

在Debug版本中,所有的参数都要验证其正确性。在正式版本中,对从外部(用户或别的模块)传递过来的参数,要验证其正确性。

2. 断言

如何验证正确性?那就要用断言(Assert)。

 

当你觉得某事肯定如何时,就可以用断言。

如果你认为某事可能会发生,这时就要写代码来处理可能发生的错误情况

4.4 代码复审

代码复审的形式

名称

形式

目的

自我复审

自己vs.自己

用同伴复审的标准来要求自己。不一定最有效,因为开发者对自己总是过于自信。如果能持之以恒,则对个人有很大好处。

同伴复审

复审者vs.开发者

简便易行。

团队复审

团队vs.开发者

有比较严格的规定和流程,适用于关键代码,以及复审后不再更新的代码。覆盖率高——有很多双眼睛盯着程序,但效率可能不高(全体人员都要到会)

 

代码复审的目的在于:

1. 找出代码的错误,比如:

         1)编码错误,比如一些碰巧骗过了编译器的错误

         2)不符合团队代码规范的地方

2. 发现逻辑错误,程序可以编译通过,但是代码的逻辑是错的

3. 发现算法错误,比如使用的算法不够优化,边界条件没有处理好等

4. 发现潜在的错误和回归性错误——当前的修改导致以前修复的缺陷又重新出现

5. 发现可能需要改进的地方

6. 教育(互相教育)开发人员,传授经验,让更多的成员熟悉项目各部分的代码,同时熟悉

         和应用领域相关的实际知识。

个人感受部分:

1、过去怎么做:

  过去都是自己一个人做任务,在结对以后有很多代码规范问题,不如两个人的代码缩进不同,没有注释等,以前都是自己写代码,自己能看懂就行,现在就对开发需要每个人都可以看懂代码,这就需要注释等

2、结合书中,这样的坏处

  如果一个团队没有明确的代码规范,这样就导致最后在将代码组成的时候出现许多错误,修改时也看不懂错误在哪里,没有注释,他人无法看懂代码

3、结合书中,改进方法

  在自己的队伍中共同明文规定一种代码书写方式,每个人的项目都要有清晰的代码注释,以方便他人阅读

posted on 2018-01-02 10:38  王行行  阅读(149)  评论(0编辑  收藏  举报

导航