'if'語句是否總是有'else'子句？

這可能是一個宗教論點，但在我的工作中，這裏已經討論過是否所有IF語句都應該包含ELSE子句 - 即使ELSE子句只包含一條評論，指出它「有意留空」。'if'語句是否總是有'else'子句？

我聽說過爭論雙方：的「對」陣營 - 確保代碼實際上已經解決的情況是否需要else子句的「反對」陣營 - 代碼更難閱讀，添加了太多的噪音

我感興趣的視圖中的任何其他點，因爲我必須解決一個答案，將滿足雙方的辯論。

謝謝你的幫助。

順便說一句：我沒有搜索StackOverflow的答案，並無法找到一個。如果有的話，只需包含一個鏈接並關閉。謝謝。

來源

2009-11-22 Jack

@Dave，這並不是說開發者無法解析其他東西;這是大多數開發人員不會期望它在那裏，所以這是不必要的噪音。有點像在你沒有要求的時候拿到肉桂。你仍然可以喝它;這只是一個不太愉快的經歷。 – 2009-11-22 23:54:47

你會推薦switch語句總是有一個默認情況嗎？ – 2009-11-23 00:08:13

你在用什麼語言工作？我一直在做這一段時間，作爲一個通用的「規則」，這個概念只是簡單的愚蠢 - 這讓我想知道是否有特殊情況。 – Murph 2009-11-23 00:30:00

130

似乎無用打字給我...和一個可能的原因造成混亂。如果你不需要它，不要放它！

來源

2009-11-22 23:23:18 jldupont

更多打字=更多錯誤機會！ – rashadb 2015-02-27 05:19:30

正如你所說，這可能是一個風格的問題，但我做夢也不會想到把空別的塊在我的代碼只是因爲「如果每塊應該有一個」。在我看來，除了代碼中的更多字符以外，它還增加了其他一些字符（很有價值的），以便在代碼審閱期間花費時間。

來源

2009-11-22 23:24:09

號如果您不需要在其上運行else側的任何代碼，你並不需要一個else條款。

來源

2009-11-22 23:24:15

編號保護條件是一個很好的例子。你可以將其餘的方法邏輯嵌套在else子句中，但它很快就會變得很難看。

來源

2009-11-22 23:25:55 peacedog

「確保代碼實際上解決的條件是否需要else子句」

這只不過是在每一個方法需要一個catch子句更真實保證了所有可能的異常已經妥善處理。

來源

2009-11-22 23:26:30

你在說阿爾戈爾派生語言嗎？

在Lisp中，我會說是的：每個IF應該有一個else子句。否則，你應該使用WHEN。

來源

2009-11-22 23:26:56 Ken

黃金法則：把它，如果它使你的代碼更清晰，更容易理解，並離開它，否則。有經驗的程序員將能夠根據具體情況做出這些判斷。

來源

2009-11-22 23:28:05 Tim

我的一般經驗法則是3+其他如果得到一個可能的空的else塊來向別人展示我的邏輯。 – Woot4Moo 2009-11-23 00:09:34

+12

@ Woot4Moo：一個潛在的空白else塊如何顯示其他人的邏輯？ – Asaph 2009-11-23 03:32:53

如果你的代碼是夠複雜，這成爲一個問題，你應該是重新考慮你的解決問題的方法。把你正在做的事分解成更小的簡單函數，這些函數應該令人難以置信地明白if語句正在做什麼。

如果你不能把它分解成更小的功能，或者你發現自己嵌套多個if語句裏面另一個，如果使用您的條件邏輯語句可能不是一個很好的選擇。考慮交換機，查找表（如果你的條件之間的唯一區別是某個常數的值）或者決策表。

如果您已經完成了所有這些工作，那麼您正在討論一些令人難以置信的小事，這幾乎不值得花時間去爭論。

來源

2009-11-22 23:28:22 Breton

微不足道的，是的。然而，當管理層決定迫使開發人員遵守這些標準時，即使是微不足道（甚至是愚蠢的）也將成爲關鍵的決定。 – Jack 2009-11-22 23:56:26

在這樣的技術問題上針對尖頭髮老闆的常見問題是工程師使用邏輯和原因。不幸的是，當一個人在與迷信和權威作鬥爭時，那些人永遠不會成功。相反，用他們的觀點來反對他們：問：「什麼是商業案例？」「如何反對既定的高效行業標準做法，使我們的產品成本更低或更有價值？」擁有更多的代碼更容易出錯，工程師理解速度更慢。 – wallyk 2009-11-25 04:42:24

要求else很臭。需要時使用它。所有的程序員都理解構造和缺失else的含義。這就像是迴應代碼的毫無意義的評論。這是平淡的IMO。

來源

2009-11-22 23:33:01 spender

這可能是一個好主意的少數可能情況之一是你有幾個嵌套if語句，但較少else子句。該語言將指定哪一個ifelse匹配，但這可能並不總是清楚的讀者。當然，如果您將內容放在大括號中，嵌套將顯而易見，所以不存在歧義。這使得這有點虛假，但仍然可能值得一提。另外，如果你的代碼很複雜，可能會有更清晰的寫法。

來源

2009-11-22 23:42:57 Tim

我同意這裏的最後一句話。任何需要這種方法的方法都太複雜，應該重構。 – 2009-11-23 13:50:26

這實際上是我試圖做的點。 – Breton 2009-11-25 05:58:44

這裏的回答清楚地表明，沒有人覺得沒有其他人需要使用。我從來沒有聽過也沒有讀過這樣的事情。在你與同事/開發者打交道之前，更重要的問題是堅定地相信這是If Then如何被使用。

聽起來你不是這種情況下的高級人物，所以你不能簡單地判斷它是如此。我建議要求「空的其他」方面展示一本關於發展的書（博客不計）如何建議這樣一個過程。更好的是，在3本關於發展的書中。自從1982年以來，我已經閱讀了我在編程語言方面的編程書籍，我從未見過這樣的建議。

這樣你就不會告訴他們他們錯了，他們可以親自採取。相反，你願意接受這樣的立場，但希望看到一些文件。他們有責任找到證據。要麼他們找到它，要麼讓他們爭辯說，每一本編寫的編程書都是錯的，只有他們是對的。

祝你好運。

來源

2009-11-23 00:07:29 dredful

有很多的「話」告訴你的方式來編程，例如在這種情況下，我會使用YAGNI幹

..你是不是要去需要它..

所以這之後你不應該寫別的。

反正在我看來，這樣不容易閱讀和理解的代碼..你越寫越難理解代碼是

編輯：這裏是您要求的鏈接： http://en.wikipedia.org/wiki/YAGNI http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

來源

2009-11-23 13:33:50 Dimitri

請鏈接或解釋您的條款 – 2010-01-21 18:55:31

至少SQL Server 2000,2005。

IF 1 = 1 
BEGIN 
    PRINT 'doing something productive' 
END 
ELSE 
BEGIN 
    --Just sitting here 
END 


Msg 102, Level 15, State 1, Line 8 
Incorrect syntax near 'END'.

您必須有一個有意義的語句，這意味着虛擬分配或返回數據到客戶端。我想我可以使用WAITFOR DELAY ...

來源

2009-11-24 20:05:34 gbn

if (thereIsSomeThingToDoInTheElse) 
{ 
    putAnElseClause(); 
} 
else 
{ 
    // intentionally left blank 
}

來源

2010-01-11 15:25:58 JoelFan

*不寒而慄*這將是有趣的調試，當註釋後的下一行被執行爲「其他」時，明顯不是打算 – CaffGeek 2010-01-11 15:44:03

是啊......我添加了大括號來修復它...謝謝 – JoelFan 2010-01-11 18:49:49

這個編輯可能是反對空的其他條款的主要原因之一 – Rado 2010-03-05 16:53:07

我傾向於使用「早期if」語句作爲減少嵌套括號的水平的裝置（或在Python縮進）像這樣：

if (inParam == null) { 
    return; 
} 

if (inParam.Value < 0) { 
    throw new ArgumentException(...,...); 
} 
// Else ... from here on my if statements are simpler since I got here.

當然，.NET 4.0現在有代碼合同，這太棒了！但是，大多數語言還沒有這樣的語言，所以「早期如果」（因爲沒有更好的術語）非常重要，因爲它們消除了許多其他子句和嵌套ifs。我認爲在高級語言中使用else子句是不利的......即使在彙編中也是如此！這個想法是：如果你檢查並沒有跳，那麼這個條件是錯誤的，我們可以繼續。具有邏輯意義，我...

編輯：看看這篇文章，以及明白爲什麼else條款是有很大幫助不： http://www.codinghorror.com/blog/2006/01/flattening-arrow-code.html

來源

2010-01-11 15:34:24

Haskell的，如果總是三元。所以別的是強制性的。

來源

2010-01-11 15:35:06 Hai

有些情況下，在不需要時使用可選語法元素可以提高可讀性或防止將來發生錯誤。一個典型的例子是圍繞一句話的條件語句括號：

做

if(foo){ 
    bar 
}

，而不是

if(foo) 
    bar

最終可以防止

if(foo) 
    bar 
    dot

我真的不能相信的任何語言，我知道在哪裏省略不必要的其他可能導致潛在錯誤： - ？

來源

2010-01-11 15:49:42

只有代碼註釋爲空的「else」通常意味着開發人員會考慮 - 通過條件並更好地瞭解給定時間實際執行的路徑。所有最近的編譯器都會刪除「else」和註釋，所以你不會減慢軟件的執行速度。

除非我錯誤地閱讀其他答案，否則它看起來像大多數人反對在代碼中聲明他們的想法所需的時間，而寧願這樣做。

來源

2010-01-21 18:00:41 Snowy

我也開始喜歡這個想法。不要盲目地把它們放在每個地方，但它肯定會使代碼更具可讀性，特別是對於塊更長的時間。此外，它有助於清楚地表達意圖。 – Rahul 2012-05-11 04:58:34

'if'語句是否總是有'else'子句？

回答

相關問題