將結果存儲在臨時變量與多個返回點中

Question

這是一種更好的做法，一般而言，爲什麼？在什麼情況下你會改變主意？

function foo1(int x) { 
    int result; 
    if (x > 5) { 
    result = 2; 
    } else { 
    result = 7; 
    } 
    return result; 
} 

OR

function foo2(int x) { 
    if (x > 5) { 
    return 2; 
    } else { 
    return 7; 
    } 
} 

Answer 1

我傾向於第二種形式，你只是立即返回。我知道的唯一的考慮如下。 優點：

• 短的代碼
• 容易按照
• 更少的變量（的部分更容易跟隨，我猜）

風險：

• 可以跳過潔淨在返回後發生的後續處理

我不擔心風險，因爲無論如何，如果您無意中將清理代碼嵌入某種條件塊中，因爲您嘗試管理保留返回值的各種執行路徑，直到結束。我認爲最好的選擇是讓代碼更簡單，更容易遵循，以避免這種風險。我認爲風險也可以通過現代語言中的編碼結構得到顯着的幫助，例如「使用」和「嘗試/最終」。我試圖總是將這些用於清理任務，而不是簡單地將代碼放在塊的末尾。

但是，當其他代碼想要作爲變量訪問掛起的返回值（例如將其添加到緩存中，以便下次可以更快地返回結果）時，我確實會發生異常。

Answer 2

我認爲最好是編寫總是執行的代碼。例如，第一個例子中的return語句總是被執行。我將分支保持在最低限度，因爲不管你多努力，你的程序遲早都會破壞。然後你會想方設法弄清楚哪些分行在哪裏執行，哪些不行。爲什麼不避免這種情況，如果程序中斷很可能幾乎是事實。 :)

Answer 3

第一個，因爲它更容易記錄和調試。

Answer 4

首先一個，是因爲以下幾個原因..

1. 如前所述的「01」，便於記錄和調試
2. 易於重構

你的代碼應該總是這樣模式..

1. 聲明變量
2. 初始化變量
3. 做加工
4. 清理!!!!
5. 返回

在此模式下，很容易讓別人理解你的代碼的行爲，到哪裏找問題，因爲總是「做加工」是你的業務邏輯保持的一部分，你可以肯定重構第三步而不影響第四和第五。如果你有機會看到大量編碼的「Windows COM/DCOM技術源代碼」，他們總是有非常標準的使用retval結構的模式，並且只有使用標準模式，一個團隊才能實現設計更大更好的系統，一個懶惰的程序員可以根據行數來編寫最小的邏輯，但對於企業應用程序來說，它永遠不會有好處。

我們花費很多錢在代碼標準工具上，我們甚至編寫了更多的代碼，然後經常需要，但在企業級別，標準實踐和不太複雜的代碼更適合維護和增長。通過這樣說，我同意即使很着急也不會多次遵循完全相同的模式，但是我也遇到了後果，當代碼變得越來越大，邏輯變得越來越複雜，邏輯重構變得越來越困難。

要編寫更少的代碼，我們使用重構，但不是難以理解的複雜邏輯。

即使你申報或不申報 retval的，如果你得到機會 反彙編代碼，你會看到 該編譯器始終在內部宣佈一個 變量用於 回報反正。

Answer 5

或

function foo2(int x) { 
    if (x > 5) { 
    return 2; 
    } 
    return 7; 
} 

Answer 6

我更喜歡第二個選項，因爲它鼓勵你去思考一件事的時間。

int MyFunction(...) 
{ 
    if (Simple case 1) 
    return 1; 
    if (Simple case 2) 
    return 2; 

    ... evaluate complex cases ... 
    return X; 
} 

你不必擔心，如果簡單的情況1適用什麼功能的其他地方根本。 一旦你過去了，如果應用簡單案例1，你不必考慮發生了什麼。

這也通常會降低縮進的級別，這往往會使事情變得更線性和易於閱讀。