2.3.2　坏代码的例子

关于好代码，上面介绍了一些特性，本节也给出坏代码（Bad Code）的几个例子。关于坏代码，本书没有做系统性总结，只是希望通过以下这些例子的展示让读者对坏代码有直观的感觉。

1. 不好的函数名称（Bad Function Name）

如do()，这样的函数名称没有多少信息量；又如myFunc()，这样的函数名称，个人色彩过于强烈，也没有足够的信息量。

2. 不好的变量名称（Bad Variable Name）

如a、b、c、i、j、k、temp，这样的变量名称在很多教科书中经常出现，很多人在上学期间写代码时也会经常这样用。如果作为局部变量，这样的名称有时是可以接受的；但如果作为作用域稍微大的变量，这样的名称就非常不可取了。

3. 没有注释（No Comments）

有写注释习惯的软件工程师很少，很多软件工程师认为写注释是浪费时间，是“额外”的工作。但是没有注释的代码，阅读的成本会比较高。

4. 函数不是单一目的（The Function has No Single Purpose）

如LoadFromFileAndCalculate()。这个例子是我编造的，但现实中这样的函数其实不少。很多函数在首次写出来的时候，就很难表述清楚其用途；还有一些函数随着功能的扩展，变得越来越庞杂，也就慢慢地说不清它的目的了。

这方面的问题可能很多人都没有充分地认识到——非单一目的的函数难以维护，也难以复用。

5. 不好的排版（Bad Layout）

不少人认为，程序可以正常执行就行了，所以一些软件工程师不重视对代码的排版，认为这仅仅是一种“形式”。

没有排好版的程序，在阅读效率方面会带来严重问题。这里举一个极端的例子：对于C语言来说，“;”可作为语句的分割符，而“缩进”和“换行”对于编译器来说是无用的，所以完全可以把一段C语言程序都“压缩”在一行内。这样的程序是可以运行的，但是对人来说，可读性非常差。这样的程序肯定是我们非常不希望看到的。

6. 无法测试（None Testable）

程序的正确性要依赖测试来保证（虽然测试并不能保证程序完全无错）。无法或不好为之编写测试用例的程序，是很难有质量保证的。