最近参加了屡次的代码review会，在review的进程中，发现有些成绩简直每次都出现。挑了几个比较典型的成绩解说下。这几个成绩都是初级成绩，处置办法都很容易。只需掌握了办法，无看法避免，能让短时间内迅速提高代码质量。真所谓投入小，奏效快。

变量命名不明晰，一词多义

为变量命名时最重要的思索事项是，该名字要 完全、准确地描画出该变量所代表的事务 。容易阅读，不会与其他事务混杂。

例如：

if(staff_id == 0) 

{ 

    printf("系统归档，不是员工归档"); 

} 

下面这段代码，staff_id是员工号的意思，用staff_id为0表示是系统归档。一词多义，本来应该把系统和人分开，但是混用到了一个变量。假设调用方出现个bug遗忘把初始化的变量赋值，还会走到不测的逻辑。

处置办法是变量称号首先要契合变量的实践意义，没有歧义；关于一个变量名，不用特定值表示特殊逻辑。

有些代码会把变量取不到的值赋予其他的意义，觉得是省事了，实践后患无量。例如用户名不能够为空，就用空值表示这个用户数据曾经被删除了。而且判定数据能否删除的代码看着也让人莫明其妙。

总之，变量命名要保证没有「潜规则」，避免给本人挖坑。

运用魔数

命名不明晰更严重的是，没有命名，直接用魔数。假设连注释都没有，就只能靠猜。

运用魔数有两个不好的中央：

1、不方便修正。

运用常量交流魔数是一种将顺序「参数化」的办法，需求修正改动一处就可以了，而不必代码中四处修正。

例如在代码中默许绑定的端口是80，假设不用一个常量替代，哪天软件晋级默许端口变成443了。要整个代码搜索80这个数字，既耗时，又容易改错。

2、代码不方便阅读。

只要一个数字，很难了解到详细的意思。

for(int i = 0; i < 13; ++i) 

{ 

    ... 

} 

下面这段代码，只看13，谁能猜出来是什么意思呢，为什么用13这个数值？能够只要写代码的人和上帝知道，假设天长日久，写代码的人遗忘了，就只要上帝知道了。

也有同窗会问，有的数字只用到一个中央，也起个常量的名字会不会太费事了？

答案是：不费事。给魔数起个好名字是应该的，这是对的事，不要由于费事就不做。有时为了起个准确的名字，甚至要查下词典。

有一个常用的判定方式：

一、假设援用魔数的中央不超过3个，直接用数字影响也不大。假设超过了3个，都是表示同一个数值意义，还是乖乖地用有意义的变量名替代。

二、假设魔数本身就是表示一个地道的数字定义，例如是几米、几千克这种，作为参数传递。在函数的定义明白表示了形参数所代表的意义。大家看用到的中央和函数定义，就知道数字是表示多少个单位的意思，可以用魔数。但是假设用数字表示种类，例如

const int ieBrowser=1; 

const int chromeBrowser=2; 

表示阅读器的种类，假设直接只是看到1或2，是不明白什么意思的。即使在函数声明的中央曾经说过是阅读器种类了，也不要用魔数。

魔数处置的办法很复杂： 用枚举、常量等方式，替代魔数 。

if else 或switch等逻辑判别语句太长

例如下面的伪代码代码，条件分支很多，用很长的if else语句或许switch语句才能表达残缺的逻辑，要思索下能否能用「表驱动」方式来优化。

const int CN=1; 

const int US=2; 

const int UK=3; 

 

string language; 

if(country==CN) 

{ 

    language="中文"; 

} 

else if(country==US) 

{ 

    language="english"; 

} 

else if(country==UK) 

{ 

    language="english"; 

} 

else 

{ 

    language=""; 

} 

条件分支太多太长有几点不好：

1、代码太长，不易阅读。

假设超过了一个屏幕能表示的长度，要翻页才能看完代码，会大大降低看代码的效率。由于代码的信息密度太低了。

2、不易扩展，修正代码。

就像下面的例子，假设又添加了新的条件判别，那么要添加新的if else语句，由于修正了逻辑，要重新测试，也要避免改错。

可以用「表驱动」的方式替代太长的逻辑分支。

把每个条件要用到的数据放到一个「表」里。用条件分支的判别条件来索引到表中的数据。

下面的代码可以修正为

const int CN=1; 

const int US=2; 

const int UK=3; 

 

(责任编辑：admin)