我对有些问题的反应感到震惊，这些问题指出开发人员更关心产生的编译字节而不是关于代码含义的问题。我倾向于选择后缀/前缀增量，因为我倾向于选择使用带有两个值的枚举类型的布尔值，以及关于正确的函数命名，以及......
所以这个问题更像是一个反复的民意调查：什么时候允许忽视一个人写的语义？边界线在哪里？
命名。
编辑 -
我并不是要质疑（微观）优化的必要性。相反，我想知道你应该意识到你正在写什么，以及“但它汇编成dword，无论如何，所以我为什么要把它作为枚举？”这样的陈述。 （这是一个极端的情况......）。
答案 0 :(得分：9)
定义“ok”。它是否可以在初始交付日期工作，但每次需要进行更改时，需要额外的三周才能找出旧代码？
有你的答案：只要你能理解代码，它就不会损害你维护代码的能力。
答案 1 :(得分：4)
我在职业生涯中写过很多的代码。当然没有像这里的许多人那么多，但仍然有很多代码。在那段时间里，我学到了一件事，一次又一次证明是真的：当你变得草率，当你忽略细节时，缺陷就会蔓延开来。
缺陷需要花费时间和金钱来修理。你可以花时间干净利落地编写代码，这样做很便宜，或者你可以花费大量的时间和金钱来追查你可能记不起来的代码中的缺陷，因为你匆忙地把它拍到一起，或者因为它不符合编码标准。最终的结果是，你浪费时间和金钱。此外，你浪费时间和金钱，你不必浪费时间，因为它可以通过一点点预先防止投资。
我从未后悔对编写代码的方式一丝不苟。它再也没有回来困扰我。草率一直困扰着我。
答案 2 :(得分：3)
当你开始担心对底线没有影响的深奥的东西时，我认为这太过分了。关于是否使用三元运算符或写明确if语句的讨论适用于那些你无事可做的日子，但是坐下来，站起来，喝啤酒/葡萄酒/苏打水并讨论“重大后果”的问题：）< / p>
但是为boolean创建一个枚举是完全错误的。
答案 3 :(得分：3)
取决于您的费用函数
这里有一些人们喜欢争论并且经常混淆的维度。真的，答案取决于它。你真正重视的是什么？
我总是首先瞄准更高阶的东西，比如清晰度。失去清晰度是在人类周期中付出的，其中总是缺乏。人们很少关心原始时钟，而那些说他们做的人几乎总是过早地进行优化。
如果它对你有帮助，我喜欢认为我们通过上升堆栈来进步，更多地关注语义和完成工作，而不是成为比特和数字的奴隶。但是，这不是忘记基本原理并记住某些语义位如何实现的借口。你不想在速度开始变得重要且会议失控的罕见机会中陷入困境。
答案 4 :(得分：3)
“什么时候允许忽略所写内容的语义？边界线在哪里？”
我认为一个合理的问题是：“当应该时，忽略了所写内容的语义？”
由于我认为编程是一种人类活动，我会说应该忽视语句语义的唯一时间是系统本身强迫你 - 当一些难以理解的语句是只有做某事的方式。这些陈述很好记录。
答案 5 :(得分：2)
边界是指处理一次写入，永不读取的代码。只有这样，你最终无所谓（在那种情况下），因为你永远不会再使用它。不幸的是，这并没有解决你不愿重复练习的间接反馈。
答案 6 :(得分：1)
边界线是副作用。
如果一个封装的函数可以完成你想要的所有0个意想不到的副作用，并且代码是可读的，那就重要了。如果您对外部用户是可预测的，并且内部保留了任何“奇异”功能，那就非常重要。
如果您添加优化，它会略有变化，但由于您不应该过早地进行优化，因此它就是结束的地方。
答案 7 :(得分：1)
我认为现在大多数人都同意，假设它正常工作，可读性是最重要的考虑因素。当然也有例外 - 一些应用程序必须尽可能快地运行，并且某些应用程序可以从不被允许崩溃，但一般来说它是可读性的。
答案 8 :(得分：1)
微观优化在99％的时间内毫无意义。例如，如果您的编译器将所有“”实例插入到单个实例中，则不会通过使用String.Empty以任何方式提高性能。没有任何可衡量的影响通常是你所能想到的最好的，我看到“优化”会降低性能，因为编译器做得更好，而且优化干扰了它。
大多数代码不需要优化。确定需要发生的位置只能在代码运行后通过诊断完成，即使这样，大部分时间都是通过算法优化完成，而不是微优化。
答案 9 :(得分：1)
观察您提供的示例 - 以下内容：
operator++（后缀/前缀）
string.empty()与string == ""
似乎不是很好的例子，因为它们会比较functionality中不同的操作。因此，一个更好的不忽视他们的语义区别。
相比之下，以下示例：
vector.empty()与vector.size() == 0
enum erate {on，off}与boolean on=true; off=false
非常合理。
vector.empty()如果其使用的上下文仅用于确定向量是否为空，则更可取。风险听起来居高临下（我确实不意图）：这归结为常识。如果您只想知道它是否为空，为什么要求矢量的大小？这就像问一个人，当你只想知道他们是否有足够的现金给可乐时，钱包里有多少钱。
至于enum erate {on，off}与boolean on=true; off=false，问问自己：将来，您在枚举中添加其他值的可能性有多大？一个人可能想要enum，on，off}`（或某些变体）似乎是合理的，所以答案可能是肯定的。否则，一个简单的布尔就足够了。
这引出了你的问题的关键：似乎是否存在一些确定性/算法方法来决定这些问题，或者它们的相关性？我的答案是，直到Turing Machines能够通过Turing Test的那天，我会说不。这就是人们需要设计软件的原因。