編碼風格......錯誤情況第一還是最後？

Question

從排序的角度來看哪個更好？你把故障狀態置於頂部還是底部？

if (noProblems == true) { 
    // do stuff 
} else { 
    // deal with problem 
} 

OR

if (noProblems == false) { 
    // deal with problem 
} else { 
    // do stuff 
} 

Answer 1

我喜歡第一消除錯誤的情況下 - 並從該函數返回初使「快樂路徑」保持未嵌套，例如

if (some error condition) 
{ 
    //handle it 
    return; 
} 
//implicit else for happy path 
... 

，如果它很容易識別通往幸福的道路條件，然後通過各種手段把該條款第（感謝馬爾辛！）

Answer 2

如果1條或2線和早日迴歸，我把它放在最上面 - 特別是如果它在功能的開始。這幾乎就像合同一樣。否則，我會隨着「積極條件前的否定」規則行事。

Answer 3

這取決於你對什麼更清楚。我的意思是，更有意義的是，沒有問題具有真正的價值，或者它具有虛假的價值。

例如，對於isDeviceEnabled（）我總是檢查一個真實的結果，因爲「Enabled」隱含了一個正值。對於一個隱式的負值，我們可以檢查例如「isMemoryAvailable（）」，也許是因爲你只需要檢查是否沒有更多的空間用於新的對象/數組或其他數據。

Answer 4

這是一個非常個人化的決定，但我傾向於把我的錯誤條件放在第一位，以代碼組合爲幌子。也就是說，如果我做了某件事，而且失敗了，那麼檢查失敗實際上是做某件事的一部分;如果我在代碼的開頭部分檢查失敗和動作，我將我的動作和對這個動作的複雜響應一起分組（假設失敗結果實際上是一個更復雜的返回情況）成功）。

Answer 5

第一個似乎稍微偏向我，因爲它避免了條件中的雙重否定。

除此之外，你已經構造的東西，讓你無法真正

// do stuff 

後您

// deal with problem 

所以超出了一個似乎與其他的好。

Answer 6

與try/catch我做了正常流程，然後處理異常情況。

這並不意味着錯誤檢查/清理不會首先發生，但是如果我不相信已經傳遞給我的東西。

例如，

if (foo is null) then 
    // bail 
end if 

if (bar == foo) then 
    // foo hasn't been changed... print the regular report 
else 
    // foo has changed, run the reconciliation report instead. 
end if 

我喜歡快樂的故事流像一條直線，而不幸遭遇分拆到自己的鞭策。

Answer 7

也許這取決於語言慣例或其他因素，但我覺得名義上的情況應該在頂部，分支機構應該包含特殊的條件。它使代碼更容易閱讀。當有許多特殊情況時，尤其如此，並且在大多數情況下都是如此。您將能夠輕易認定作者期望大部分時間都能採用這種特定路徑，並以這種方式更容易理解代碼。

從「代碼完成，第二版」第15.1節：

通過將最常見的情況先，您最大限度地減少異常情況處理代碼的人的數量已經閱讀找到通常情況下。 您可以最大限度地減少代碼執行測試以查找最常見情況的次數，從而提高效率。

Answer 8

爲什麼不創建一個函數退出點，並做適當的清理了，而不是有多個回報......

 

DWORD bRetVal= TRUE; 
if(foo is null) 
{ 
    bRetVal = FALSE; 
    goto Error; 
} 
else 
{ 
// do something 
} 

Exit: 
return bRetVal;