90%的程序员都犯过的代码错误

 

最近参加了屡次的代码review会，在review的过程当中，发现有些问题几乎每次都出现。挑了几个比较典型的问题讲解下。这几个问题都是初级问题，解决方法都很容易。只要掌握了方法，有意识避免，能让短期内迅速提升代码质量。真所谓投入小，见效快。

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

为变量命名时最重要的考虑事项是，该名字要彻底、准确地描述出该变量所表明的事务。容易阅读，不会与其余事务混淆。

例如：

if(staff_id == 0)
{
    printf("系统归档，不是员工归档");
}

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

解决方法是变量名称首先要符合变量的实际意义，没有歧义；对于一个变量名，不用特定值表示特殊逻辑。

有些代码会把变量取不到的值赋予其余的意义，感受是省事了，实际后患无穷。例如用户名不可能为空，就用空值表示这个用户数据已经被删除了。并且断定数据是否删除的代码看着也让人莫名其妙。

总之，变量命名要保证没有「潜规则」，防止给本身挖坑。

使用魔数

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

使用魔数有两个很差的地方：

一、不方便修改。

使用常量替换魔数是一种将程序「参数化」的方法，须要修改改动一处就能够了，而没必要代码中处处修改。
例如在代码中默认绑定的端口是80，若是不用一个常量代替，哪天软件升级默认端口变成443了。要整个代码搜索80这个数字，既耗时，又容易改错。

二、代码不方便阅读。

只有一个数字，很难了解到具体的意思。

for(int i = 0; i < 13; ++i)
{
    ...
}

上面这段代码，只看13，谁能猜出来是什么意思呢，为何用13这个数值？可能只有写代码的人和上帝知道，若是天长日久，写代码的人忘记了，就只有上帝知道了。

也有同窗会问，有的数字只用到一个地方，也起个常量的名字会不会太麻烦了？

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

有一个经常使用的断定方式：

1、若是引用魔数的地方不超过3个，直接用数字影响也不大。若是超过了3个，都是表示同一个数值意义，仍是乖乖地用有意义的变量名代替。

2、若是魔数自己就是表示一个纯粹的数字定义，例如是几米、几千克这种，做为参数传递。在函数的定义明确表示了形参数所表明的意义。你们看用到的地方和函数定义，就知道数字是表示多少个单位的意思，能够用魔数。可是若是用数字表示种类，例如

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="";
}

条件分支太多太长有几点很差：

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

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

二、不易扩展，修改代码。

就像上面的例子，若是又增长了新的条件判断，那么要增长新的if else语句，因为修改了逻辑，要从新测试，也要防止改错。

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

把每一个条件要用到的数据放到一个「表」里。用条件分支的判断条件来索引到表中的数据。
上面的代码能够修改成

const int CN=1;
const int US=2;
const int UK=3;

string languageTable[]={"","中文","English","English"};
//先判断country变量是否在定义的CN、US、UK范围内，若是在继续
language = languageTable[country];

通过修改，代码变得很短，一眼就能看出代码所表示的逻辑。并且之后更新的只有数据，逻辑部分不用修改。

使用「表驱动」后，逻辑和数据分离。使得新增数据修改简单，并且一目了然。

总结

上面只是简单的说明了几种常见的代码书写错误。稍加注意，就可以在短期内迅速提高代码质量。具体的方法能够参考一些代码规范，或者重构的书籍，例如「表驱动」会有更详尽的介绍。

最本质的仍是要从意识上有足够的认识。代码是写给人看的，写代码时要有同理心，想到之后让阅读代码的人尽可能可以不费力读懂。换位思考，若是你就是review人，或后面接手这个代码的人，你会喜欢这段代码吗？

毕竟代码阅读的次数远远超过编写的次数。确保代码阅读方便，而不只是编写方便。

​