我對有很多關於問題的反應感到有點震驚，它指出開發人員更關心結果編譯字節而不是他們代碼的含義。我傾向於挑選關於後綴/前綴增量，因爲我傾向於挑選使用具有兩個值的枚舉類型的布爾值，以及有關正確的函數命名，並且...誰在乎......只要結果是好的？
所以問題更多一個反思性的民意調查：什麼時候可以忽視人們寫作的語義？邊界線在哪裏？
名字。
編輯 -
我不是故意的關於需要（微）-optimizations質疑。相反，我想知道你應該怎樣認識你寫的東西，以及諸如「但它編譯成雙字，爲什麼我應該把它作爲枚舉？」等語句。 （這是極端的情況......）。
我已經寫了很多我的職業生涯中的代碼。當然不是很多人在這裏，但很多代碼。在那段時間裏，我學到一件事情，我們再次證明是正確的時間和時間：當你馬虎，當你忽略的細節，缺陷蠕變
缺陷維修費用的時間和金錢。你可以花時間在代碼乾淨而清晰的時候編寫代碼，這樣做很便宜，或者你可以花費大量的時間和金錢來追逐代碼中的缺陷，而這些代碼可能不記得那麼好，因爲你匆匆把它放在一起，或者因爲它不符合編碼標準。最終的結果是，你浪費時間和金錢。此外，您不必浪費時間和金錢就可以開始使用，因爲它可能會因爲一點前期投資而被阻止。
我從不後悔對編寫代碼的方式一絲不苟。它從來沒有回來困擾我。 sl has一直回來困擾着我。
邊界線是副作用。
如果一個封裝的函數做了所有你想要的並且意想不到的副作用，並且代碼是可讀的，那就重要了。如果您對外部用戶可預測，並且內部持有任何「奇異」功能，那就很重要。
如果您添加優化，它會稍微改變，但是因爲您不應該過早地進行優化，那就是它的結束位置。
定義「ok」。如果它在初始交付日期有效，它可以嗎？但是，每當您需要進行更改時，需要額外三個星期才能找出舊代碼？
有你的答案：只要你能理解代碼，它不會損害你的維護能力。
我認爲現在大多數人都認爲，假設它正常工作，可讀性是最重要的考慮因素。當然也有例外 - 一些應用程序必須儘可能快地運行，並且一些應用程序可以允許從未崩潰，但通常來說它是可讀性的。
當您處理一次性寫入，無法讀取的代碼時，邊界是。只有這樣，它最終不會影響你在做什麼（在這種情況下），因爲你永遠不會再使用它。不幸的是，這並沒有解決你不想重複練習的間接反饋。
取決於你的成本函數
以下幾個層面的人喜歡爭論，而且往往混爲一談。真的，答案是取決於。你真正重視什麼？
我總是首先瞄準更高階的東西，比如清晰度。失去清晰度是在人類的週期中支付的，其中一直存在短缺。人們很少關心原始時鐘，而那些表示他們的人幾乎總是過早地進行優化。
如果它對你有幫助，我喜歡認爲我們正在通過上升堆棧取得進展，更多地關注語義和完成工作，而不是成爲位和數字的奴隸。但是，這不是忘記基礎知識並記住某些語義位如何實現的藉口。在速度開始變得重要且常規消失的罕見機會期間，您不想讓自己的褲子陷入困境。
「什麼時候可以忽略寫入內容的語義？邊界線在哪裏？」
我認爲一個合理的問題是：「什麼時候應該一個人忽略了什麼人寫的語義？
因爲我認爲編程是一種人類活動，我想說的只是一個時間應該忽略一個語句的語義是當系統本身迫使你 - 當一些難以理解的語句是唯一的方式做一些東西。這些聲明很好記錄。
這是一個有價值的轉折！ – xtofl 2009-01-27 21:52:49
微觀優化在99％的時間內毫無意義。例如，如果你的編譯器無論如何都將所有的「」實例都實例化爲單個實例，那麼你不會通過使用String.Empty來以任何方式提高性能。沒有任何可衡量的效果通常是最好的，你也可以期望，因爲編譯器做得更好，而且優化會干擾它，所以我看到「優化」會降低性能。
大多數代碼不需要優化。識別需要發生的地方只能在代碼運行後通過診斷來完成，即使這樣，大部分時間都是通過算法優化完成的，而不是微觀優化。
我甚至沒有談論優化。更像是：如果你不使用它，就不要付錢，甚至更像是：表達你的意思，而不是你認爲可能對編譯器有所幫助。 – xtofl 2009-01-27 21:50:14
觀察，你所提供的例子 - 以下：
operator++（後綴/前綴）
string.empty()與string == ""
似乎並不爲好例子，因爲它們比較在functionality中不同的操作。因此，一個更好的而不是忽視他們的語義區別。
與此相反，下面的例子：
vector.empty()與vector.size() == 0
enum {中心提供全方位on，off}對booleanon=true; off=false
完全合理。
vector.empty()是優選的，如果其使用的上下文僅用於確定該向量是否爲空。在風險聽起來居高臨下（我做不打算打算）：這歸結爲常識。爲什麼要問矢量的大小，如果你只是想知道它是空的？這就像問一個人他們錢包裏有多少錢，當你只是想知道他們是否有足夠的可樂兌現可口可樂時。
至於enum erate {on,off}與booleanon=true;請問自己：有多大可能在將來爲枚舉增加另一個值？看起來合理的是，人們可能想要enum提供{,off,indeterminate}（或一些變化），所以答案可能是肯定的。否則，一個簡單的布爾值就足夠了。
這將我引向問題的癥結所在：這似乎是否存在某種確定性/算法方法來決定這些問題或其他問題或其相關性？我的答案是，直到Turing Machines能夠通過Turing Test的那一天，我會說沒有。這就是爲什麼人類需要設計軟件的原因。
語言/平臺？ – chakrit 2009-01-27 18:47:39
如果它是一個民意調查，它不應該是一個維基？ – 2009-01-27 18:51:48