將幾行代碼寫入一行是否有益（就內存和空間復雜性而言）。 這值得么？

Question

示例：交換兩個編號的簡單程序。

 int a = 10;
 int b = 20;
 a = a+b;
 b = a-b;
 a = a-b;

現在在下面的代碼中：

 a=a+b-(b=a);

我的意思是這兩個代碼的黑白區別是什么？

加法：如果這兩個的加法超出了Integer的合法限制（在Java和C ++情況下是不同的），該怎么辦？

Answer 1

這些對我來說都不好。 可讀性是關鍵。 如果要交換值，最“顯而易見”的方法是通過一個臨時值：

int a = 10;
int b = 20;

int tmp = a;
a = b;
b = tmp;

我既不知道，也通常不關心這是否和涉及算術的“聰明”方法一樣有效。 除非有人證明在實際應用程序中性能差異顯着，否則我將一直致力於最簡單可行的代碼。 不僅在這里，而且對於所有代碼。 確定您需要它執行的性能（以及在什么尺寸上），對其進行測試，並根據需要將其更改為更復雜但更有效的方法 。

（當然，如果平台中有可用的swap操作，請改用它，甚至更清楚。）

Answer 2

在C ++中，代碼產生未定義的行為，因為a+b-(b=a)沒有序列點，並且您正在更改b並從中讀取。

您最好使用std::swap(a,b) ，它已針對速度進行了優化，並且比您所擁有的更具可讀性 。

Answer 3

由於您的特定代碼已被注釋，因此我只添加一個一般方面。 編寫一個襯板並不重要，因為在指令級別，您無法逃避匯編將轉換為機器代碼的步驟數。 大多數編譯器已經進行了相應的優化。

也就是說，除非一個內聯函數實際上使用了不同的機制來實現例如在交換兩個變量的情況下的目標，否則，如果您不使用第三個變量，並且可以避免所有障礙（例如類型溢出等）並使用按位運算符例如，那么您可能已經保存了一個存儲位置，從而可以訪問它。

實際上， 這幾乎沒有任何價值，並且在可讀性方面也有麻煩，正如其他答案中已經提到的那樣。 人們需要維護專業程序，因此它們應該易於理解。

好的代碼的一種定義是， 代碼實際上會執行它似乎正在做的事情

如果您巧妙地編寫了一些縮短了但又復雜的操作的代碼，即使您自己也將發現很難修復自己的代碼。 可讀性應始終放在優先位置，在大多數情況下，真正需要的效率來自改進設計，方法或更好的數據結構/算法，而不是短線。

引用Dijkstra ： 稱職的程序員完全意識到自己頭骨的大小。 因此，他滿懷謙卑地完成自己的任務，並避免了諸如瘟疫之類的巧妙技巧。

Answer 4

幾點：

• 代碼首先應該反映您的意圖 。 畢竟，它是供人類閱讀的。 在那之后，如果確實需要，則可以開始調整代碼以提高性能。 大多數人從不編寫代碼來證明a頭或有點不休。
• 將代碼分成多行絕對不會影響性能。
• 不要小看編譯器的優化器。 只需盡可能直觀地編寫代碼，優化器將確保其具有最佳性能。

在這方面，最具描述性，直觀性和最快的代碼是：

std::swap(a, b);

Answer 5

可讀性和即時理解性是我個人在編寫和閱讀代碼時的評價（以及其他一些人可能會贊成的）。 它提高了可維護性。 在提供的特定示例中，很難立即理解作者在這幾行中想要實現的目標。 單行代碼： a=a+b-(b=a); 盡管非常聰明，但顯然不能將作者的意圖傳達給他人。

就效率而言，編譯器的優化無論如何都會實現這一點。

Answer 6

至少在Java方面，我記得讀過JVM針對常規的直接使用進行了優化，因此，如果您嘗試執行此類操作，那么您常常會自欺欺人。

而且它看起來糟透了。

Answer 7

好，試試看 下次遇到一個奇怪的錯誤時，請先將盡可能多的代碼壓縮為一行。

請等待幾周，以免您忘記了它應該如何工作。

嘗試調試它。

Answer 8

當然，這取決於編譯器。 盡管我無法預見到任何令人震驚的差異。 惡意代碼是主要代碼。