在試圖達到所有綠色時，我通過Resharper得到了以下建議。Resharper的代碼建議使代碼不易讀？
原始代碼：
static public string ToNonNullString(this XmlAttribute attr)
{
if (attr != null)
return attr.Value;
else
return string.Empty;
}
建議：刪除多餘的 '其他' 導致以下：
static public string ToNonNullString(this XmlAttribute attr)
{
if (attr != null)
return attr.Value;
return string.Empty;
}
對我來說，建議的版本似乎比原來少了可讀性。 Resharper的建議是否反映了良好可維護代碼的定義？
從技術上講，Resharper是正確的，因爲「其他」是不必要的，我更喜歡前一版本，儘管意圖更明顯。
話雖如此，我寧願去：
return attr != null ? attr.Value : string.Empty;
三元運營商的可讀性呃？ *關鍵vulcan眉毛培養* – 2009-01-22 00:41:14
+1，是的，我發現它更易讀 - 爲什麼人們如此害怕條件操作員？ – 2009-01-22 07:48:56
因爲我必須尋找操作符才能看到不同的零件。 – 2009-01-22 07:58:21
我同意你的代碼的第一個版本更具可讀性。
我發現在這些情況下，Resharper建議並不總是有幫助，雖然有時它可以清理乾淨。這就是爲什麼我將Resharper配置爲顯示更改爲「提示」而非「建議」。這會導致綠色下劃線不易看到，並且不會在右側邊欄中突出顯示。
+1用於提示將檢查降級爲提示。我認爲在這種情況下，保護條款是可取的，但有時候我寧願爲了對稱而留下多餘的「else」。 – 2010-10-06 19:35:32
啊，代碼美觀。聖戰時間。 （鴨）
我會去用或者是：表達：
return attr != null ? attr.Value : String.Empty
，或者如果反轉並刪除換行符產生guard clause：
if (attr == null) return String.Empty;
return attr.Value;
你的原代碼更具可讀性和可理解性 - 一目瞭然，您可以準確查看導致返回string.Empty的條件。如果沒有else，您必須看到之前在if區塊中有回報。
只要記住，你是一個人類，本質上比機器更聰明。如果它告訴你一些更好，但你不同意，那麼不要聽它。
我注意到了關於ReSharper的同樣的事情，所以我很欣賞它能夠關閉某些項目或降級他們的警告級別。我也很困惑這個建議：
SomeClass varName = new SomeClass（）;
建議更改爲：
var varName = new SomeClass（）;
是的，我知道，我不需要初始申報類型，但感覺奇怪，表明變種形式是某種優於其他。是否有人熟悉這個建議背後的基本原理，或者你是否同意我的看法，這個也很奇怪？
當您使用較小的樣本量時，經常會遇到各種異常的經典示例。將一個巨大的if-elseif-else塊重構爲guard子句佈局會使代碼更具可讀性，但正如您所說，如果將相同的規則應用於單個if-else，那麼它就沒有那麼有用。我甚至可以說這是一個（輕微）缺乏遠見的resharper開發人員不要跳過像這樣的小塊，但它是無害的。
我認爲新版本是好多了，如果您反轉，如果
static public string ToNonNullString(this XmlAttribute attr)
{
if (attr == null)
return string.Empty;
return attr.Value;
}
因爲你原來的版本太對稱，而空的情況是一個特例。
新版本在「大多數情況下會返回什麼？」這個術語中更具可讀性。
我的一些同事從他們編輯的頁面開始使用Resharper在佈局和可讀性方面糟糕透頂。我很高興地說它沒有生存，沒有人在這裏再次使用它。
關於手頭上的聲明，我同意Jeffrey Hantin的內聯 - 如果對於這種類型的聲明非常好，Whatsit的解決方案非常適合。除了一些例外，我（personaly）說方法/函數應該只有1個return語句。
另外如果你（幾乎）總是用你的if來實現else（即使它只是一個註釋行，說你對else語句沒有做任何事情），它會迫使你更經常地考慮這種情況比不可以防止錯誤。
這兩種說法都應該用來作爲一種「思考」，而不是像一個規則，就像大多數這類問題一樣，總是用你的大腦:)當你不這樣做時，大多數錯誤都會發生。
結論：對Resharper說不！ （是的，我真的不喜歡Resharper，對不起）
作爲C＃的noob，更習慣C和Java我還是不習慣在C＃.NET和VS中放置尖括號。把所有這一切放在一邊，我同意安德烈在反轉'如果'是更可讀。另一方面，我個人發現省略'else'會降低可讀性（略）。我會去與該個人的看法：
static public string ToNonNullString(this XmlAttribute attr)
{
if (attr == null)
return string.Empty;
else
return attr.Value;
}
如果你不喜歡ReSharper的建議的東西的方式，只是禁用具體建議（斜線警告斜線提示）。編碼風格也是如此，我認爲這是高度可配置。聲稱ReSharper是無法使用的（引用「我很高興地說它沒有生存，沒有人再使用它了）」，只是因爲你不花5分鐘才知道如何配置它只是簡單的愚蠢。
當然，你不應該讓某些工具指定你的編碼風格的某些部分，如果你不告訴它，ReSharper不會這麼做。就這麼簡單。
我要添加的唯一東西將不得不與表達式的長度有關。就個人而言，我很喜歡三元表達式的緊湊性，但是把像
if (testDateTime > BaseDateTime)
return item.TransactionDate <= testDateTime && item.TransactionDate >= BaseDateTime;
return item.TransactionDate >= testDateTime && item.TransactionDate <= BaseDateTime;
成類似
return testDateTime > BaseDateTime ? item.TransactionDate <= testDateTime && item.TransactionDate >= BaseDateTime : item.TransactionDate >= testDateTime && item.TransactionDate <= BaseDateTime;
並沒有真正似乎對我很有幫助。
我的編碼標準是總是使用括號（即使只有一條指令後，如果命令）
這是需要一點努力（多輸入），但我經常確信，這是非常值得的！
一個最常見的錯誤（和矛盾很難找到）被加入後，額外的指令if語句，忘記加括號...
所以我喜歡ReSharper的建議的內容。尤其是當已經嵌套if語句：
假設我們有這樣的代碼：
if (condition1) {
instruction1;
}
else {
if (condition2) {
instruction2;
}
}
可以改成這個樣子：
if (condition1) {
instruction1;
}
else if (condition2) {
instruction2;
}
這是更可讀給我，然後之前。
當它涉及到的最佳實踐和編碼標準（這也將是較明顯的，當你有超過2級以上的嵌套語句）
它總是值得商榷。其中一個原因是無法使用Visual Studio等IDE輕鬆實施它們。有像FxCop和StyleCop這樣的工具可以用來分析標準的代碼。 FxCop用於編譯代碼分析，StyleCop用於源代碼分析。
您可以將StyleCop配置爲一分鐘級別，以確定要應用於代碼的格式。有一個名爲StyleCop的加載項用於Resharper，它在Visual Studio中提供了Suggessions。我有一個詳細的博客文章大約在 http://nileshgule.blogspot.com/2010/10/refactoring-clean-code-using-resharper.html
resharper版本更好，因爲'attr！= null'條件可以被視爲早期救助（或用例異常路徑），允許函數繼續完成其主要任務。 （既沒有贏得高分，也沒有多少回報）。
在這種情況下，我會說MrWiggles單線是最好的選擇。
*嘗試去所有綠色* < - 你做錯了。 – jwg 2014-02-17 17:46:45
C＃6.0變體：`return attr？.Value ?? string.Empty;` – Brian 2016-03-14 18:35:55