开发人员是否应该首先考虑可读性或性能？
通常情况下，开发者将面临两种解决问题的可能方式之间的select – 一个是惯用的，可读的，另一个不那么直观，但可能performance更好。 例如，在基于C的语言中，有两种方法可以将数字乘以2：
int SimpleMultiplyBy2(int x) { return x * 2; } 和
int FastMultiplyBy2(int x) { return x << 1; }
第一个版本对技术和非技术读者来说都比较简单，但是第二个版本可能performance更好，因为位移比乘法更简单。 （现在，让我们假设编译器的优化器不会检测到并优化它，但这也是一个考虑因素）。
作为一个开发人员，这将是一个更好的初始尝试？
你错过了一个。
第一个正确的代码，然后为了清晰（当然两者往往是连接的！）。 最后，只有当你有真正需要的经validation据时，才能看到优化。 不成熟的优化确实是邪恶的。 优化几乎总是花费你的时间，清晰度，可维护性。 你最好确定你正在购买一些有价值的东西。
请注意，好的algorithm几乎总是能够胜过本地调优 没有理由你不能有正确，清晰，快速的代码。 不过，如果你开始专注于“快速”的话，你将会有不合理的幸运。
海事组织首先明显的可读版本，直到测量性能和更快的版本是必需的。
从Don Knuth那里拿来
不成熟的优化是编程中所有邪恶（或至less大部分）的根源。
可读性100％
如果你的编译器不能为你做“x * 2”=>“x << 1”优化 – 得到一个新的编译器！
另外请记住，您的程序的99.9％的时间花在等待用户input，等待数据库查询和等待networking响应。 除非你多做了20个百万倍，否则不会引人注目。
在你给出的例子中，99.9999％的编译器会为这两种情况生成相同的代码。 这说明了我的一般规则 – 先写可读性和可维护性，然后只在需要时进行优化。
可读性肯定。 除非有人抱怨，否则不要担心速度
可读性。
对性能进行编码有它自己的一套挑战。 Joseph M. Newcomer说得很好
优化只在重要时才有意义。 重要的事情很重要，但是直到你知道事情的重要性，不要浪费很多时间去做。 即使你知道它很重要，你需要知道它的重要性。 没有性能数据，你不知道要优化什么，你可能会优化错误的东西。
结果将是模糊的，难以编写，难以debugging，并且难以维护的代码不能解决您的问题。 因此，它具有（a）增加软件开发和软件维护成本，（b）完全没有性能效果的双重缺点。
可读性。 优化的时间是在进行betatesting的时候。 否则，你永远不知道你需要花费什么时间。
我会首先去阅读 。 考虑到我们现在使用这种优化的语言和大量的机器，我们以可读的方式编写的大部分代码都会performance得很好。
在一些非常罕见的情况下，你肯定会有一些性能瓶颈（可能来自过去的一些不好的经验），并且你设法find一些可以给你巨大性能优势的怪异技巧，你可以去那。 但是，您应该很好地评论该代码段，这将有助于使其更具可读性。
在这个争论中经常被忽视的一个因素是程序员需要额外的时间去浏览，理解和修改较less可读的代码。 考虑到一个程序员的时间是一个小时或更多的时间，这是一个非常实际的成本。
任何性能收益都会受到这个直接额外开发成本的影响。
在那里写一个解释会让它更易读，更快。
这实际上取决于项目的types，以及performance的重要性。 如果你正在构build一个3D游戏，那么通常会有许多共同的优化，你会一路上想要扔在那里，没有理由不要（不要太早）过早地把它扔掉。 但是，如果你正在做一些棘手的事情，请评论一下，这样看着它的任何人都会知道如何以及为什么你会变得棘手。
答案取决于上下文。 例如在设备驱动程序编程或游戏开发中，第二种forms是可接受的习惯用法。 在商业应用中，不是那么多。
最好的select是环视代码（或类似的成功应用程序）来检查其他开发人员如何执行此操作。
使用<<会通过微观优化。 所以霍尔（不是Knuts）的规则：
不成熟的优化是万恶之源。
适用，你应该首先使用更可读的版本。
这是规则，恕我直言，经常滥用作为借口来devise软件，永远不能扩展，或performance不错。
都。 你的代码应该平衡两者; 可读性和性能。 因为忽视任何一个都会影响到项目的投资回报率，这对于你的老板来说是最重要的。
可读性差导致可维护性下降，导致更多的资源花费在维护上，导致ROI降低。
业绩不佳会导致投资和客户群减less，导致投资回报率降低。
代码库越大，可读性就越重要。 试图了解一些微小的function并不是那么糟糕。 （尤其是因为这个例子中的方法名字给了你一个线索。）对于一个独立的天才编写的一些史诗般的超级代码，他刚刚退出编码，并不是那么好，因为他终于看到了他的能力的复杂性的顶端，这就是他只是写给你，你永远不会理解它。
如果您担心代码的可读性，请随时添加评论以提醒您自己，以及为什么要这样做。
位移与乘法是一个无关紧要的优化 。 而且，正如已经指出的那样，你的编译器应该为你做。 除此之外，无论如何，这个指令运行的CPU都是可以忽略的。
另一方面，如果您需要执行严格的计算，您将需要正确的数据结构。 但是，如果你的问题很复杂，找出解决办法的一部分。 作为说明，请考虑在1000000个未sorting的对象数组中searchID号。 然后重新考虑使用二叉树或哈希映射。
但是像n << C这样的优化在任何时候通常都是可以忽略和微不足道的。 让代码可读不是。
这取决于需要解决的任务。 通常可读性更加重要，但是当你首先考虑性能时，仍然有一些任务。 在一切正常完成之后，你不能只花一天时间或进行性能分析和优化，因为优化本身可能需要重新编写代码的足够部分。 但现在并不普遍。
你应该总是最大限度地优化，性能永远是重要的。 我们之所以今天是英国媒体，是因为大多数程序员不想做优化工作。
话虽如此，你可以随时把意见放在需要澄清的地方。
如果你不知道自己的瓶颈，那么优化就毫无意义。 你可能已经做了一个令人难以置信的高效的函数（通常以某种程度上的可读性为代价），只是发现代码几乎没有运行，或者花费更多的时间击中磁盘或数据库，而不是节省多余的代码。 所以你不能微观优化，直到你有一些东西要衡量，那么你也可以从可读性开始。 但是，在devise整体架构时，您应该注意速度和可理解性，因为两者都可能产生巨大的影响，难以改变（取决于编码风格和方法）。
据估计，软件成本的70％左右正在维护中。 可读性使系统更容易维护，从而降低了软件的使用寿命。
有些情况下，performance更重要的可读性，说他们是less之又less。
在牺牲可读性之前，请考虑一下：“我（或你的公司）是否准备好处理我通过这样做所增加的额外成本？
我不在谷歌工作，所以我会去邪恶的select。 （优化）
在Jon Bentley的“Programming Pearls”的第6章中，他通过在6个不同的devise层次上进行优化，描述了一个系统如何加快了400倍。 我相信，通过不关心这六个devise级别的性能，现代实现者可以轻松地在他们的程序中实现2-3个数量级的减速。
几乎每个人都在回答中说，我赞成可读性 。 我运行的100个项目中有99个没有硬响应时间要求，所以这是一个简单的select。
在你开始编码之前，你应该已经知道答案了。 有些项目有一定的性能要求，比如“需要能够在Y（毫秒）秒内运行任务X”。 如果是这样的话，你有一个目标，你需要知道什么时候需要优化。 （希望）这是在项目的需求阶段确定的，而不是在编写代码时确定的。
良好的可读性和稍后优化的能力是正确的软件devise的结果。 如果您的软件具有完善的devise，那么您应该能够隔离部分软件，并根据需要重新编写软件，而不会破坏系统的其他部分。 此外，我遇到的大多数真正的优化案例（忽略了一些真正的低级技巧，这些都是偶然的）已经从一种algorithm转换到另一种algorithm，或者将数据caching到内存而不是磁盘/networking。
可读性是第一个目标。
在二十世纪七十年代，军队testing了软件开发的一些“新”技术（自顶向下的devise，结构化编程，主程序员团队等等），以确定哪一个在统计上有显着差异。
唯一的技术，在统计上显着的发展差异是…
添加空白行到程序代码。
这些预先结构化的，面向对象的代码的可读性的提高是这些研究中提高生产力的唯一技术。
==============
只有在整个项目进行了unit testing并准备好仪器之后才能优化。 你永远不知道你需要优化代码。
在1970年代后期的“软件工具”（1976）和“软件工具”（1981）中，Kernigan和Plauger在他们的标志性书籍中展示了使用自顶向下devise创build结构化程序的方法。 他们创build了文本处理程序：编辑器，search工具，代码预处理器。
当完成的文本格式化function是INSTRUMENTED时，他们发现大部分的处理时间花费在三个执行文本input和输出的例程中（在原书中，io函数占用了89％的时间，在pascal书中，这些函数消耗55％！）
他们能够优化这三套程序，并以合理，可pipe理的开发时间和成本产生更高性能的结果。
可读性第一。 但是，可读性甚至超过了简单性， 特别是在数据结构方面。
我想起一个学生正在做一个视觉分析程序，他不明白为什么这么慢。 他只是遵循了良好的编程习惯 – 每个像素都是一个对象，它通过向邻居发送消息来工作。
看一下这个
如果没有可读性，在真正需要的时候很难提高性能。
性能只应该在程序中出现问题时才有所改善，有很多地方会成为瓶颈，而不是这种语法。 假设你正在捣鼓1英寸的改进，但是忽略了10分钟的IO时间。
此外，关于可读性，专业程序员应该能够阅读/理解计算机科学术语。 例如，我们可以命名一个方法入队，而不是我们必须说putThisJobInWorkQueue。
首先写可读性，但期望读者成为程序员 。 任何值得加盐的程序员应该知道乘法和偏移之间的区别，或者能够正确地读取三元运算符，能够查找并理解复杂的algorithm（您正在评论您的代码是否正确？ ）等等
早期的过度优化当然是很糟糕的，当你需要重构的时候，你会遇到麻烦，但是这并不适用于单个方法，代码块或者语句的优化。
我会说为了可读性去。
但在给定的例子中，我认为第二个版本已经足够可读了，因为函数的名字正好说明了函数中发生了什么。
如果我们总是有function告诉我们，他们做什么…
一小时的处理器时间花费多less钱？
一个小时的程序员花费多less时间？
恕我直言，这两件事情没有任何关系。 你应该首先找出可行的代码，因为这比性能或读取的效果更重要。 关于可读性：在任何情况下，您的代码应始终可读。
但是我不明白为什么代码不可读，同时提供良好的性能。 在你的例子中，第二个版本和第一个版本一样可读。 什么是不太可读的呢？ 如果一个程序员不知道左移和右移相同，右移与右移两个相同，那么你的基本问题比一般的可读性要多得多。
