如何评价一段代码

什么样的代码才算是好代码？这个问题其实见仁见智，业内也没有统一的标准可以使用。有人总结了以下五个评价指标。结合自己的编写代码感悟，颇为有感。

• 规模
• 执行效率
• 占用空间
• 可读性
• 扩展性
  

这五个维度相互之间有着或强或弱的关联，任意两份代码之间可以参考这个体系进行大概的比较，但没有绝对的高下之分。结合自己的感悟，平常最着重的还是可读性和执行效率这两点，扩展性比较不容易把握，可能在不同阶段对扩展性的要求不一样。

---

规模

这里的规模说的是代码的规模，也就是解决同样问题的程序包含的代码行数。如果单从这个因素讲，那一定是代码规模越小越好。但规模越小往往就会让代码本身的复杂程度变高，影响可读性。

执行效率

从某种意义上讲，如今对程序的第一要求应该就是执行效率。人们说的最多的就是执行效率和运行空间的关系，还有执行效率和可读性的关系。

以空间换时间

随着硬件设备的成本越来越低，越来越多的行业都提倡以空间换时间的设计思想。一些能够通过记录中间数据减少计算量的地方就成了首选的优化点。

最经典的利用这个思想的算法就是桶排序：
代码如下：

#include "stdafx.h"
#include<iostream>

int main()
{
    int arr[10] = { 2,5,15,18,7,10,13,11,9,0 };
    int arrSort[20] = { 0 };
    for (int i = 0; i < 10; i++)
    {
        arrSort[arr[i]]++;
    }

    for (int i = 0; i < 20; i++)
    {
        if (arrSort[i] > 0)
        {
            std::cout << i << std::endl;
        }
    }

    system("pause");
    return 0;
}

运行结果：

这段代码通过一个空间为20的一维数组下标进行排序，空间利用是土豪级的。它的特点是排序范围有多大，就需要一个多大的数组。

不能牺牲可读性

底层程序员喜欢用位运算，于是常有人把简单的计算用位运算进行优化，比如把

int a = 10;
int b = a / 2;

改成

int a = 10;
int b = a >>1;

由于位运算的物理特性，下面这段代码的确效率会更高一些。不过，很多人看到这种写法都不一定能反应上来。

占用空间

对于一些特殊的行业，比如嵌入式开发，编程过程中一定要注意的就是节省空间。因为嵌入式设备的RAM普遍比较小。这时候，桶排序的方法一定是不允许的。另外，在申请堆空间时都有严格的限制。

嵌入式开发中常有类似这样的代码：

#define NEED_MAX 800
int* p = new int[NEED_MAX];
if (p == NULL)
{
    return -l;
}

delete[] p;

没有嵌入式经验的人一定会问，这段代码申请了一段空间后什么也没做就释放掉了，这不是画蛇添足吗。其实，这是一段容错代码，就是为了保证系统中有足够的空间供后面的代码执行。

是不是想想就很可怜，程序运行中突然发现内存不够了，不得不停掉。

可读性

对于越来越提倡代码规范的中国软件行业来说，可读性开始成为不可忽视的重要因素。无论是统一的代码风格，还是规范的命名、函数设计和注释，这些都必须注意。

在某些公司，代码规范被认为是评价代码的第一要素（个人非常认同这点）。铁打的项目流水的程序员，一段可读性差的代码对项目而言很可能意味着灭顶之灾。

行业内有一些沿袭了很久的陋习，因为追求程序执行效率损失可读性、为了减少代码行数损失可读性、为了赶工期损失可读性甚至还有为了省事儿损失可读性。在这些思想的驱使下，产生了很多不好的代码习惯。

void Swap(int& a, int& b)
{
    a = a ^ b;
    b = a ^ b;
    a = a ^ b;
}

这是一个实现变量交换功能的函数，它利用了^运算的特性，完成了不借助第三个变量进行交换的动作。有些公司的面试题甚至还会考这个（个人碰到好几次）。但无论从执行效率还是从输入效率来讲，它都没有什么优势。也许唯一的作用就是炫技。

如果你仔细阅读任意一个公司的代码规范文档，你都会发现它有一条最重要的指导思想，那就是为了提高代码可读性，允许牺牲一些其他方面的利益。

扩展性

对于一些大型的、生命周期久的项目而言，扩展性相当重要。但扩展性有一个死敌就是代码量。仔细研究一下经典的23种设计模式，没有哪一个不是成倍地提高了代码量。

在很多资深程序员中，还常常因为是否使用设计模式引发争论。而这些争论的焦点就是代码量和扩展性这对矛盾。究竟这二者孰轻孰重呢，其实也没有一定之规，完全取决于具体的项目情况。具体问题具体分析才是王道。

这里补充一点，不要为了扩展性而扩展，如同使用设计模式，不要为了设计模式而使用设计模式，自己把问题搞复杂了，程序维护起来会很麻烦。

参考资料：
http://www.jianshu.com/p/4df3473de6f9?from=jiantop.com