如何评价一段代码

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

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

这五个维度相互之间有着或强或弱的关联,任意两份代码之间可以参考这个体系进行大概的比较,但没有绝对的高下之分。

1. 规模

图1:如何评价一段代码

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

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

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:如何评价一段代码

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

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. 可读性

图3:如何评价一段代码

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

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

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

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

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. 初学者的权衡

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

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

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

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

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

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

本文文字及图片出自 www.jianshu.com

余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注