性能与可读性

Question

阅读这个问题我发现这是(注意引号)"代码"来解决问题(顺便说一下,这是perl).

100,{)..3%!'Fizz'*\5%!'Buzz'*+\or}%n*

显然这是一个没有真实的智力实例(我希望永远不会在我生活中的真实代码中看到它),但是,当你必须做出选择时,你何时牺牲代码的可读性才能获得性能？你是否只是应用常识,你是否总是作为最后的手段？你有什么策略？

编辑:对不起,看到答案我可能已经表达了严重的问题(英语不是我的母语).我不是说你编写代码后的性能与可读性,我在你写之前也会问.有时你可以通过制作一些较暗的设计或提供一些会使你的课程变暗的属性来预见未来的性能提升.您可能决定使用多个线程或仅使用一个线程,因为您期望这些线程可以提供的可伸缩性,即使这会使代码更难以理解.

Answer 1

在我认为性能可能成为问题的情况下我的流程:

1. 让它起作用.
2. 讲清楚.
3. 测试性能.
4. 如果存在有意义的性能问题:重构速度.

请注意,这不适用于更高级别的设计决策,这些决策在以后更难以更改.

Answer 2

我总是从我能想到的最易读的版本开始.如果性能是一个问题,我重构.如果可读版本难以概括,我重构.

关键是要进行良好的测试,以便重构很容易.

我认为可读性是代码中最重要的问题,尽管正常工作紧随其后.

Answer 3

可读性是最重要的.使用现代计算机,只有最苛刻的应用程序中最密集的例程需要过多担心性能.

Answer 4

我最喜欢这个问题的答案是：

1. 让它起作用
2. 改正它
3. 快一点

在事情的范围内，除了下一个必须照顾您的代码的不幸傻瓜之外，没有人会对可读性发表任何评论。但是，话虽如此……如果您认真对待自己的艺术，并且这是一种艺术形式，那么您将始终努力使您的代码尽可能具有最佳性能，同时仍可供其他人阅读。我的朋友和导师（在各方面都是坏蛋）曾经在一次代码审查中亲切地告诉我，“傻瓜编写只有他们能理解的代码，天才编写任何人都能理解的代码。” 我不确定他从哪里得到的，但它一直困扰着我。

参考