经常有人微信问我，什么样的代码才算是好代码。这个问题其实见仁见智，业内也没有统一的标准可以使用。我仔细梳理了一下自己评价代码的方法，总结了五个评价指标。

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

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

有个很有趣的情况，初学者和技术大牛两种水平相差巨大的人都有对代码规模的执念。不过他们的诉求却是完全不同的。

1.1 初学者追求简单

初学者评价代码是不是简单的最朴素的方法就是看代码规模，他们总是觉得代码行数越少的程序就越简单。经常有人在微信中问为什么我给出的解法要写二十几行代码，而网上的解法却只有十几行。于是就让我讲一下那个十几行的代码。我只能说，那个十几行的代码来自《算法导论》，我需要用4~5个篇幅来讲，还不保证能讲透彻。

在编程领域，往往简单并不表示易懂，它可能蕴含着更高级更复杂的思想。这些对于初学者是有难度的。

for (k = 0; k < n; k++) 
{ 
    for (i = 0; i < n; i++) 
    { 
        for(j = 0; j < n; j++) 
        { 
            if (D[i][j] > D[i][k] + D[k][j]) 
            { 
                D[i][j] = D[i][k] + D[k][j]; 
                P[i][j] = P[i][k]; 
            } 
    } 
}  

这是一个计算临接矩阵中任意两点之间距离的一个经典算法，叫Floyd，只有六行代码。当年参加ACM比赛的时候就死记硬背下了这段代码，后来一直没有仔细研究过这个算法的原理，目前也只是会用而已。在大部分情况下，它也不是最优的算法。

1.2 大牛们追求省事

真正的大牛追求代码行数少的原因一定是为了提高执行效率，但也不乏一些从业多年没养成好习惯也被人称为“大牛”的人仗着自己经验丰富图省事的一些写法。我就见过这样的代码：

typedef struct _tagNode
{
    int m_nID;
    int m_nSN;
    int m_nMode;
    int m_nCode;
}Node;

Node arrNodes[100];

本来应该写这段代码定义一个数据结构，结果被某位“大牛”写成这样：

int arr[100][4];

九行代码一下变成了一行，就为了少敲一些。当然，换做初学者，这样的二维数组可能已经驾驭不了。我还见过更夸张的代码：

int arr[100][50][30][5];

写这行代码的人依然是个有多年工作经验的“大牛”，这个四维数组用的风生水起。只是坑苦了后来接手他工作的同事。

这样追求代码规模的行为都是不可取的。

2. 执行效率

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

2.1 以空间换时间

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

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

void 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)
        {
            printf("%d ", i);
        }
    }
}

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

2.2 不能牺牲可读性

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

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

改成

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

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

3. 占用空间

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

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

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

delete[] p;

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

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

4. 可读性

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

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

对于初学者，代码规范这个要素必须非常重视，如果错过了这个培养良好习惯的黄金时期，后面再改就很难了。

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

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

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

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

在如今的编译技术中，这段代码已经能够被优化到一个相当高的性能了。

再举个例子：

 g_nScore = student.GetScore() >= p->m_pNext->m_nScore ? student.GetScore() : p->m_pNext->m_nScore;

这句话还是尽量写成下面这种形式：

if (student.GetScore() >= p->m_pNext->m_nScore)
{
    g_nScore = student.GetScore();
}
else
{
     g_nScore = p->m_pNext->m_nScore;
}

虽然功能上没有问题，但下面这种写法更有助于开发者理清自己的逻辑。

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

5. 扩展性

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

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

6. 初学者的权衡

对于初学者而言，究竟哪些指标应该最关注呢？我认为，当然是可读性。

初学者学习编程时，最重要的一点就是能够把朴素的算法用编程语言来实现。其他的都不重要。有时，过早地追求其他四种指标会让你误入歧途。

面对一道题目的多种解法，你要去做选择首先该去钻研哪一个。是那个代码函数最少的吗？是那个运行时间最短的吗？是那个开辟空间最少的吗？还是那个扩展性最强的。这些都不是，应该是那个可读性最好的。

可读性好的代码一般都不是最短的那一个，但一定是你最容易学会的。当你掌握了一个正确的解法之后，你的心里就有了底，之后再了解其他解法时就更加自信，学习的动力就这样悄悄地到来了。

很多新同学害怕代码量大的程序，所谓的代码量大也不过三四十行代码，一看到就先紧张。其实，当你静下心来以子功能为单位一点点地读下去，你会发现它不过是几道课后作业解法的简单堆叠，并不难理解。相反，很多看似简单只有十几行代码的程序往往是一个大坑，一旦你扎进去，凭自己的本事根本爬不出来。

可能我说的这些很多初学者还无法明白，没关系先记住，相信在不久的将来你完成了一定数量的练习之后，你就会明白我今天在讲些什么。

我是天花板，让我们一起在软件开发中自我迭代。
如有任何问题，欢迎与我联系。