首页 > 代码库 > 第四章

第四章

 

①代码规范

每个人对于什么是“好”的代码规范未必认同,这时我们很有必要给出一个基准线—什么是好的代码规范和设计规范

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

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

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

② 代码风格规范

代码风格的原则是:简明易读无二义性 
提示:这里谈的风格是一家之言,如遇争执,关键是要本着“保持简明,让代码更容易读”的原则,看看争执中的代码规范能否让程序员们更好地理解和维护程序

2.1 缩进

是用Tab键好,还是2、4、8个空格? 
结论4个空格,在Visual Studio和其他的一些编辑工具中都可以定义Tab键扩展成为几个空格键。不用Tab键的理由是,Tab键在不同的情况下会显示不同的长度,严重干扰阅读体验。4个空格的距离从可读性来说,正好

2.2 行宽

行宽必须限制,但是以前有些文档规定的80字符行宽太小了(以前的计算机/打字机显示行宽为80字符),现在时代不同了,可以限定为100字符

2.3 括号

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

2.4 断行与空白的{ }行

1. 最精简的格式A:

if (condition)  DoSomething(); 
else    DoSomethingElse();
优点:因为可以节省几行 缺点:不同的语句(Statement)放在一行中,程序调试(Debug)起来非常不方便,如果要一步一步观察condition中各个变量(condition可能是包含函数调用的复杂表达式)的变化情况,单步执行就很难了

2. 有断行的格式B:
if (condition)
    DoSomething(); 
else 
    DoSomethingElse();
缺点:由于没有明确的“{”和“}”来判断程序的结构,在有多层控制嵌套时,这样的格式就不容易看清结构和对应关系

3. 改进的格式C
if (condition) {
    DoSomething(); 
} else {
    DoSomethingElse();
}

缺点:不够清晰

4. 每个“{”和“}”都独占一行,即格式D
if (condition) 
{ 
    DoSomething(); 
} 
else 
{ 
    DoSomethingElse(); 
}

2.5 分行
不要把多条语句放在一行上
a =1; b =2;      // bogus
if (fFoo) Bar();   // bogus

更严格地说,不要把多个变量定义在一行上
Foo foo1, foo2;    // bogus
2.6 命名
用单个字母给有复杂语义的实体命名并不可取,也是经过了实践检验的方法叫“匈牙利命名法”。例如:
fFileExist  // 表明是一个bool值,表示文件是否存在;
szPath  // 表明是一个以0结束的字符串,表示一个路径

2.7 下划线

下划线用来分隔变量名字中的作用域标注和变量的语义,如:一个类型的成员变量通常用m来表示,或者简单地用一个下划线“”来做前缀。移山公司规定下划线一般不用在其他方面

2.8 大小写

由多个单词组成的变量名,如果全部都是小写,很不易读,一个简单的解决方案就是用大小写区分它们。

  • Pascal——所有单词的第一个字母都大写
  • Camel——第一个单词全部小写,随后单词随Pas-cal形式,这种方式也叫lowerCamel

一个通用的做法是:

  • 所有的类型/类/函数名都用Pascal形式,所有的变量都用Camel形式
  • 类/类型/变量:名词或组合名词,如Member、ProductInfo等
  • 函数则用动词或动宾组合词来表示,如get/set、RenderPage()

2.9 注释

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

//this loop starts the i from0 to len, in each step, it
// does SomeThing
for (i =0; i < len; i++)
{
    DoSomeThing();
}

以上的注释是多余的。注释是为了解释程序做什么(What),为什么这样做(Why),以及要特别注意的地方,如下
/go thru the array, note the last element is at [len-1]
for (i =0; i < len; i++)
{
    DoSomeThing();
}

复杂的注释应该放在函数头,很多函数头的注释都用来解释参数的类型等,如果程序正文已经能够说明参数的类型in/out,就不要重复! 
注释也要随着程序的修改而不断更新,一个误导的(Misleading)注释往往比没有注释更糟糕 
另外,注释(包括所有源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性。 
在现代编程环境中,程序编辑器可以设置各种美观得体的字体,我们可以使用不同的显示风格来表示程序的不同部分。

注意:有些程序设计语言的教科书对于基本的语法有详细的注释,那是为了教学的目的,不宜在正式项目中也这么做

3. 代码设计要规范
4. 代码复审
正确定义:看代码是否在“代码规范”的框架内正确地解决了问题

软件工程中最基本的复审手段,就是同伴复审

1. 代码复审的目的在于

  • 找出代码的错误,比如:

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

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

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

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

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

  • 发现可能需要改进的地方

  • 教育(互相教育)开发人员,传授经验,让更多的成员熟悉项目各部分的代码,同时熟悉和应用领域相关的实际知识

结对编程

结对编程的优势
  1. 在开发层次,结对编程能提供更好的设计质量和代码质量,两人合作解决问题的能力更强

  2. 对开发人员自身来说,结对工作能带来更多的信心,高质量的产出能带来更高的满足感

  3. 在企业管理层次上,结对能更有效地交流,相互学习和传递经验,分享知识,能更好地应对人员流动

总之,如果运用得当,结对编程可以取得更高的投入产出比(Return of Investment)

第四章