开发人员是否应该首先考虑可读性或性能？

Question

通常情况下,开发人员将面临解决问题的两种可能方式之间的选择 - 一种是惯用的和可读的,另一种不太直观,但可能表现更好.例如,在基于C语言中,有两种方法可以将数字乘以2:

int SimpleMultiplyBy2(int x)
{
    return x * 2; 
}

和

int FastMultiplyBy2(int x)
{
    return x << 1;
}

第一个版本更容易为技术和非技术读者选择,但第二个版本可能表现更好,因为比特移位比乘法更简单.(现在,让我们假设编译器的优化器不会检测到它并对其进行优化,尽管这也是一个考虑因素).

作为开发人员,最初的尝试会更好吗？

Answer 1

你错过了一个.

首先是正确性的代码,然后为了清楚起见(当然,两者经常连接!).最后,只有你有真正需要的实证证据,你才能看到优化.过早的优化确实是邪恶的.优化几乎总是花费您的时间,清晰度和可维护性.你最好确定你买的是有价值的东西.

请注意,好的算法几乎总是胜过本地化调整.没有理由你不能拥有正确,清晰和快速的代码.你会非常幸运地开始关注"快速".

Answer 2

IMO是首先显而易见的可读版本,直到测量性能并且需要更快的版本.

Answer 3

从Don Knuth那里拿走它

过早优化是编程中所有邪恶(或至少大部分)的根源.

Answer 4

可读性100%

如果您的编译器无法为您执行"x*2"=>"x << 1"优化 - 获取新的编译器!

还要记住,99.9%的程序时间用于等待用户输入,等待数据库查询和等待网络响应.除非你做了20多亿次的多次,否则它不会引人注意.

Answer 5

在您给出的示例中,99.9999%的编译器将为这两种情况生成相同的代码.这说明了我的一般规则 - 首先编写可读性和可维护性,并仅在需要时进行优化.

Answer 6

可靠性肯定.除非有人抱怨,否则不要担心速度

Answer 7

可读性.

对性能进行编码有其自身的一系列挑战.Joseph M. Newcomer说得很好

优化只有在重要时才有意义.重要的是,这很重要,但在你知道这很重要之前,不要浪费很多时间去做.即使你知道这很重要,你也需要知道它的重要性.如果没有性能数据,您将不知道要优化什么,并且您可能会优化错误的东西.

结果将是模糊的,难以编写,难以调试,并且难以维护无法解决问题的代码.因此,它具有以下双重缺点:(a)增加软件开发和软件维护成本,以及(b)根本没有性能影响.

Answer 8

可读性.优化的时间是进行beta测试的时间.否则你永远不会真正知道你需要花时间.

Answer 9

我会首先考虑可读性.考虑到这些日子我们所使用的优化语言和大量加载的机器,我们以可读方式编写的大多数代码都能正常运行.

在一些非常罕见的情况下,你很确定你会有一些性能瓶颈(可能来自过去的一些糟糕体验),并且你设法找到了一些可以给你带来巨大性能优势的奇怪技巧,你可以去那.但是你应该很好地评论该代码片段,这将有助于使其更具可读性.