标签 代码 下的文章

最近关于 Linus Torvalds 的一个采访中,这位 Linux 的创始人,在采访过程中大约 14:20 的时候,提及了关于代码的 “good taste”。good taste?采访者请他展示更多的细节,于是,Linus Torvalds 展示了一张提前准备好的插图。

他展示的是一个代码片段。但这段代码并没有 “good taste”。这是一个具有 “poor taste” 的代码片段,把它作为例子,以提供一些初步的比较。

Poor Taste Code Example

这是一个用 C 写的函数,作用是删除链表中的一个对象,它包含有 10 行代码。

他把注意力集中在底部的 if 语句。正是这个 if 语句受到他的批判。

我暂停了这段视频,开始研究幻灯片。我发现我最近有写过和这很像的代码。Linus 不就是在说我的代码品味很差吗?我放下自傲,继续观看视频。

随后, Linus 向观众解释,正如我们所知道的,当从链表中删除一个对象时,需要考虑两种可能的情况。当所需删除的对象位于链表的表头时,删除过程和位于链表中间的情况不同。这就是这个 if 语句具有 “poor taste” 的原因。

但既然他承认考虑这两种不同的情况是必要的,那为什么像上面那样写如此糟糕呢?

接下来,他又向观众展示了第二张幻灯片。这个幻灯片展示的是实现同样功能的一个函数,但这段代码具有 “goog taste” 。

Good Taste Code Example

原先的 10 行代码现在减少为 4 行。

但代码的行数并不重要,关键是 if 语句,它不见了,因为不再需要了。代码已经被重构,所以,不用管对象在列表中的位置,都可以运用同样的操作把它删除。

Linus 解释了一下新的代码,它消除了边缘情况,就是这样。然后采访转入了下一个话题。

我琢磨了一会这段代码。 Linus 是对的,的确,第二个函数更好。如果这是一个确定代码具有 “good taste” 还是 “bad taste” 的测试,那么很遗憾,我失败了。我从未想到过有可能能够去除条件语句。我写过不止一次这样的 if 语句,因为我经常使用链表。

这个例子的意义,不仅仅是教给了我们一个从链表中删除对象的更好方法,而是启发了我们去思考自己写的代码。你通过程序实现的一个简单算法,可能还有改进的空间,只是你从来没有考虑过。

以这种方式,我回去审查最近正在做的项目的代码。也许是一个巧合,刚好也是用 C 写的。

我尽最大的能力去审查代码,“good taste” 的一个基本要求是关于边缘情况的消除方法,通常我们会使用条件语句来消除边缘情况。你的测试使用的条件语句越少,你的代码就会有更好的 “taste” 。

下面,我将分享一个通过审查代码进行了改进的一个特殊例子。

这是一个关于初始化网格边缘的算法。

下面所写的是一个用来初始化网格边缘的算法,网格 grid 以一个二维数组表示:grid行 。

再次说明,这段代码的目的只是用来初始化位于 grid 边缘的点的值,所以,只需要给最上方一行、最下方一行、最左边一列以及最右边一列赋值即可。

为了完成这件事,我通过循环遍历 grid 中的每一个点,然后使用条件语句来测试该点是否位于边缘。代码看起来就是下面这样:

for (r = 0; r < GRID_SIZE; ++r) {
    for (c = 0; c < GRID_SIZE; ++c) {
        // Top Edge
        if (r == 0)
            grid[r][c] = 0;
        // Left Edge
        if (c == 0)
            grid[r][c] = 0;
        // Right Edge
        if (c == GRID_SIZE - 1)
            grid[r][c] = 0;
        // Bottom Edge
        if (r == GRID_SIZE - 1)
            grid[r][c] = 0;
    }
}

虽然这样做是对的,但回过头来看,这个结构存在一些问题。

  1. 复杂性 — 在双层循环里面使用 4 个条件语句似乎过于复杂。
  2. 高效性 — 假设 GRID_SIZE 的值为 64,那么这个循环需要执行 4096 次,但需要进行赋值的只有位于边缘的 256 个点。

用 Linus 的眼光来看,将会认为这段代码没有 “good taste” 。

所以,我对上面的问题进行了一下思考。经过一番思考,我把复杂度减少为包含四个条件语句的单层 for 循环。虽然只是稍微改进了一下复杂性,但在性能上也有了极大的提高,因为它只是沿着边缘的点进行了 256 次循环。

for (i = 0; i < GRID_SIZE * 4; ++i) {
    // Top Edge
    if (i < GRID_SIZE)
        grid[0][i] = 0;
    // Right Edge
    else if (i < GRID_SIZE * 2)
        grid[i - GRID_SIZE][GRID_SIZE - 1] = 0;
    // Left Edge
    else if (i < GRID_SIZE * 3)
        grid[i - (GRID_SIZE * 2)][0] = 0;
    // Bottom Edge
    else
        grid[GRID_SIZE - 1][i - (GRID_SIZE * 3)] = 0;
}

的确是一个很大的提高。但是它看起来很丑,并不是易于阅读理解的代码。基于这一点,我并不满意。

我继续思考,是否可以进一步改进呢?事实上,答案是 YES!最后,我想出了一个非常简单且优雅的算法,老实说,我不敢相信我会花了那么长时间才发现这个算法。

下面是这段代码的最后版本。它只有一层 for 循环并且没有条件语句。另外。循环只执行了 64 次迭代,极大的改善了复杂性和高效性。

for (i = 0; i < GRID_SIZE; ++i) {
    // Top Edge
    grid[0][i] = 0;

    // Bottom Edge
    grid[GRID_SIZE - 1][i] = 0;
    // Left Edge
    grid[i][0] = 0;
    // Right Edge
    grid[i][GRID_SIZE - 1] = 0;
}

这段代码通过每次循环迭代来初始化四条边缘上的点。它并不复杂,而且非常高效,易于阅读。和原始的版本,甚至是第二个版本相比,都有天壤之别。

至此,我已经非常满意了。

那么,我是一个有 “good taste” 的开发者么?

我觉得我是,但是这并不是因为我上面提供的这个例子,也不是因为我在这篇文章中没有提到的其它代码……而是因为具有 “good taste” 的编码工作远非一段代码所能代表。Linus 自己也说他所提供的这段代码不足以表达他的观点。

我明白 Linus 的意思,也明白那些具有 “good taste” 的程序员虽各有不同,但是他们都是会将他们之前开发的代码花费时间重构的人。他们明确界定了所开发的组件的边界,以及是如何与其它组件之间的交互。他们试着确保每一样工作都完美、优雅。

其结果就是类似于 Linus 的 “good taste” 的例子,或者像我的例子一样,不过是千千万万个 “good taste”。

你会让你的下个项目也具有这种 “good taste” 吗?


via: https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a

作者:Brian Barto 译者:ucasFL 校对:wxy

本文由 LCTT 组织编译,Linux中国 荣誉推出

是什么造就了一个优秀的程序员?首先问问你自己吧,这会是个有趣的问题。它让你反思自己的软件开发技术。这个问题也适合问问你的同事们。它可以带来一些关于如何协同工作的有趣讨论。下面是我认为成为一个优秀程序员必备的五个重要技能。

1. 分解问题

编程是为了解决问题,但在你开始写代码前,需要明白如何解决问题。优秀程序员的一项技能是把大的问题逐层分解成一个个更小的部分,直到每一部分都可以很容易解决。但找到解决问题的方式往往并没有那么简单。优秀程序员能找到方法去建立问题模型,这种方法使得输出结果的程序容易解释、实现和测试。

我写过的某些最复杂的程序在局部上都是难懂的,因为代码实现并不能很好地匹配这个问题,也就导致了编写的代码难以理解。当问题很好地建模的时候,我赞同伯尼·科赛尔所说的话(取自著名的程序员在工作中的访谈记录):

“……很少有本质上很难的程序。如果你盯着某一块代码,它看起来确实很难;如果你无法理解这段代码应该产生什么结果,这基本上就是暗示它很难被理解了。在这个时候,你不应该卷起袖子,尝试修复代码;你需要只是往回一步,再仔细考虑清楚。当你已经深思熟虑后,你会发现问题变得很简单”。

2. 场景分析

优秀开发者能考虑到如何使程序适合多种不同的场景。这项能力既适用于处理程序本身的逻辑,又适用于处理可能会发生的外部和内部事件。为了考虑逻辑上的不同思路,他们问自己这样的问题:如果这个参数为空会发生什么?如果所有条件都为假呢?这个方法在线程上是安全的吗?为了发现软件需要处理的各种类型的事件,他们问自己这样的问题:如果队列占满了会怎样?如果请求收不到响应会怎样?如果在这台服务器重启的同时另外一台服务器也重启了会怎样?

优秀程序员问他们自己:如何发现程序的缺陷?换句话说,他们有能力像测试人员一样思考。相反,缺少经验的程序员通常只考虑正确的路径——在一切都按照预期进行时正常的控制流(当然这也是程序在大部分时候的情况)。当然,异常不可避免要发生,所以需要程序能处理这些情况。

3. 命名

编程由大量的命名对象组成:类、方法和变量。当编码完成得很好时,程序也具备了自我描述的能力,也就是说通过阅读源代码可以清楚地明白程序中函数的含义。自描述代码的一个好处就是很自然地产生许多更短的命名方法,而不是少数更长的方法,因为你有更多空间去放置有意义的名字(还有其它原因解释为什么短小方法更好)。

想出好的名字比它听起来更困难一些。我喜欢这段引用(来自菲尔·卡尔顿):“在计算机科学领域只有两件困难的事情:缓存失效和命名对象。”命名在一定程度上很困难是因为你需要清楚地明白每一个名字究竟要代表什么。有时候命名不是一下子就清晰明了,只有随着软件开发进展才会慢慢显现。因此,重命名和命名一样重要。

命名对象也包含提出要用的概念和这些概念该如何称呼。通过深思熟虑,清楚命名所使用的惯用概念(在程序中和与程序员、非程序员讨论时使用),这使得编写程序变得更加容易。

4. 一致性

也许编程中最大的挑战是管理复杂性。保持一致性是处理复杂性的一种方法。它通过允许我们看到对象命名、使用和处理所采用的模式和推理来降低了某些复杂性。有了一致性,我们就无需用脑去记住异常和随机变量。取而代之,我们可以更关注程序本身的复杂性,而不是偶然产生的复杂性

保持一致性从整体看来是很重要的。它应用在变量名字和分组、方法命名、模块划分、目录结构、GUI、错误处理、日志输出和文档等很多方面。比如,如果某些变量是的相关,并一起出现(在声明、方法调用或数据库中的列),而且总是以相同的顺序使用它们。那么当其中一个消失或者整体被打乱时,你就会很容易发现。对于一个操作,如果在一个地方叫delete,就不要在另一个地方叫remove:务必使用相同的名字。史蒂夫·麦克奈尔在代码大全中对于使用相反命名有相同的建议。比如,begin和end是相反的,就如同start和stop一样。当使用相反对时不要混用不同对的名字(比如使用begin和stop)。

当修改一段程序时可能会引入非一致性。粗心大意的程序员不会注意到他们添加的代码是否和已有的代码保持一致。优秀程序员会严苛地确保在这些看似很小的细节上都要做到精益求精。他们知道保持一致性对于在软件开发的整个过程中处理复杂性是多么的重要。

5. 学习能力

作为一名软件开发者,你需要持续学习。在为软件添加一项新功能前,你必须明白为什么要这么做。在给一个已有程序添加代码前,你通常必须知道已有代码在做什么,以便合适地嵌入新功能。你还需要学习相关系统,以便正确地与它们交互。因此,快速学习的能力使你成为一名更加高效的开发者。

而且,因为软件工程领域的开发速度是如此的快速,所以新的编程语言、工具、技术和框架需要学习层出不穷。这是好还是坏,就看你怎么看。佛瑞德·布鲁克斯把学习能力列为技能的快乐之一,对此我深表赞同。学习新事物本身就是令人心满意足的,它也意味着开发者的生活从不无聊。

总结

上面所有的技能都是通用的——它们中没有一项是针对某种语言、某个框架或某种技术。如果你拥有它们,你就能快速学习一门新的语言或工具,在新的环境下写出优秀的软件。而且,因为它们在本质上是通用的,所以不会在若干年以后过时。

是什么造就了一个优秀的程序员?以上便是我的观点。你认为造就一个优秀程序员的因素有哪些?在评论里告诉我吧。


via: http://henrikwarne.com/2014/06/30/what-makes-a-good-programmer/

作者:Henrik Warne 译者:KayGuoWhu 校对:Caroline

本文由 LCTT 原创翻译,Linux中国 荣誉推出

Coverity开启了免费开发测试服务,允许任何对开源软件质量感兴趣的人查看项目

来自美国山景城(加州)的消息:Coverity公司(新思科技公司的一个子公司)发布了2013年Coverity扫描开源软件报告。

经过Coverity扫描服务以及按照Coverity开发测试平台的商业惯例,报告中详细分析了关于7.5亿行开源软件代码的分析,这是至今报告研究的最大的样本量。

在2013年Coverity扫描报告中,他们分析了超过700个C/C++开源项目和一个匿名的企业项目的样本。另外,报告中还强调了几个流行的开源Java项目的分析结果,这些项目从2013年3月就加入了扫描服务。

Coverity扫描开源项目报告成为了一个被广泛接受的衡量开放源代码质量状态的标准。在过去8年时间里,Coverity扫描服务分析了超过1500个开源项目的数亿行代码——其中包括的C/C++项目中有NetBSD, FreeBSD,LibreOffice和Linux等,Java项目中有Apache Hadoop,HBase以及Cassandra等。

自2006年已来,扫描服务帮助开发者发现和修复了超过94,000缺陷。仅在2013年一年就修复了近50,000个缺陷——这是扫描服务的用户在一年中修复缺陷的最大数量。在这些缺陷中,其中有超过11,000的缺陷修复出现在扫描服务中的四个最大的项目:NetBSD,FreeBSD,LibreOffice和Linux。

2013年报告中重要发现包括:

C/C++项目中开源软件代码质量超过专有软件

缺陷密度(每1,000行软件代码所含的缺陷)是一个通用的测量软件质量的方法,缺陷密度1.0被认为是高质量软件的公认的行业标准。

Coverity的分析中发现,扫描服务中的开源的C/C++项目的平均缺陷密度为 0.59,而为企业项目开发的专有C/C++代码的缺陷密度为 0.72。在2013年,在所有不同大小的代码库中,扫描服务中的开源项目的代码质量超过专有项目,这进一步强调了开源社区开发测试的坚定的承诺。

Linux继续成为开源质量的基准

通过利用扫描服务,Linux将修复一个新发现的缺陷的时间从122天减少到仅6天!从2008年第一个Coverity扫描报告发布后,扫描过的Linux版本的缺陷密度一直小于1.0。在2013年,Coverity扫描了超过850万行Linux代码并发现缺陷密度为 0.61。

C/C++开发者修复了更多的高风险缺陷

Coverity分析报告发现贡献于开源Java项目的开发者修复的高风险缺陷的数量没有贡献于开源C/C++项目的开发者修复的多。

参加扫描服务的Java项目开发者只修复了13%的被指出的资源泄露,而C/C++项目开发者则修复了46%。这一方面可能是因为Java编程社区错误的安全感的原因,这种安全感是因为内建于语言的保护,比如垃圾收集。然而,垃圾收集是不可预测的,而且不能访问系统资源,所以这些项目处于危险之中。

HBase是Java项目的基准

Coverity分析了100个开源Java项目的超过800万行代码,包括流行的大数据项目Apache Hadoop 2.3 (320,000 行代码)和Apache Cassandra (345,000 行代码)。

自从在2013年8月加入扫描服务以来,Apache HBase (Hadoop的数据库)修复了超过220个缺陷,其中包括比其他参加扫描服务Java项目更高比例的资源泄露(HBase的缺陷中资源泄露占的比例为66%,而其他项目平均为13%)。

“如果说软件正在吞食世界,那么开源软件则是带头冲锋,”Coverity的产品高级总监Zack Samocha说,“我们的目标,包括Coverity扫描服务在内是帮助开源软件社区创作高质量的软件。基于这个报告的结果——以及这个日益流行的服务——使用开发测试的开源软件项目继续提升他们软件的质量,这让他们使整个行业更上一层楼。”

Coverity今天也宣布已经开放了Coverity扫描服务,允许任何对开源软件感兴趣的人查看参与项目的进展。个人现在可以成为项目观察者,这使他们可以跟踪扫描服务中相关开源软件的状态,查看高级数据包括未解决和已修复的缺陷的数目以及缺陷密度。

“我们看到了请求扫描服务的人数的指数增长,他们仅仅是要监控被发现和被修复的缺陷。在许多情况下,这些人工作于大型的企业组织,那些企业组织在商业项目中使用开源软件,”Samocha补充说。“通过对个人开放扫描服务,我们提升了查看开源项目代码质量的新的可见度,他们的软件供应链中正包含这些项目。”


via: http://www.ciol.com/ciol/features/213112/coverity-scan-report-source-software-quality-outpaces-proprietary-code/page/1

译者:linuhap 校对:Caroline

本文由 LCTT 原创翻译,Linux中国 荣誉推出