在尝试全绿时，我得到了 Resharper 的以下建议。
原始代码：
static public string ToNonNullString(this XmlAttribute attr)
{
if (attr != null)
return attr.Value;
else
return string.Empty;
}
建议：删除多余的“else”，结果如下：
static public string ToNonNullString(this XmlAttribute attr)
{
if (attr != null)
return attr.Value;
return string.Empty;
}
对我来说，建议的版本似乎比原来的可读性差。Resharper 的建议是否反映了良好可维护代码的定义？
从技术上讲，Resharper 是正确的，因为“else”是不必要的，但我更喜欢前一个版本，因为意图更明显。
话虽如此，我宁愿选择：
return attr != null ? attr.Value : string.Empty;
啊，代码美学。圣战时期。（鸭子）
我会选择一个 ?: 表达式：
return attr != null ? attr.Value : String.Empty
或反转 if 并删除换行符以生成保护子句：
if (attr == null) return String.Empty;
return attr.Value;
我认为如果您反转 if，新版本会更好
static public string ToNonNullString(this XmlAttribute attr)
{
if (attr == null)
return string.Empty;
return attr.Value;
}
因为您的原始版本过于对称，而 null-case 是一种特殊情况。
新版本在“它大部分时间返回什么？”方面更具可读性。
我同意您的代码的第一个版本更具可读性。
在这些情况下，我发现 Resharper 的建议并不总是有帮助，尽管有时它可以清理问题。这就是为什么我将 Resharper 配置为将更改显示为“提示”而不是“建议”。这会导致绿色下划线不太明显，并且不会在右侧边栏中突出显示。
如果您不喜欢 ReSharper 建议的方式，只需禁用特定建议（斜线警告斜线提示）。编码风格也是如此，我认为它是高度可配置的。声称 ReSharper 无法使用（引用“我很高兴地说它无法生存，这里没有人再使用它了”）只是因为您不需要 5 分钟来了解如何配置它，这简直是愚蠢的。
当然，您不应该让某些工具支配您的编码风格的某些部分，如果您告诉 ReSharper 不这样做，它就不会这样做。就是这么简单。
您的原始代码更具可读性和可理解性 - 一目了然，您可以准确地看到导致string.Empty返回的条件。如果没有，您必须看到在此之前的块else中有返回。if
请记住，您是人类，天生比机器更聪明。如果它告诉你某件事更好，而你不同意，那就不要听它。
我的编码标准总是使用括号（即使 if 命令之后只有一条指令）
这需要一点努力（更多的打字），但我经常相信这是非常值得的！
最常见的错误之一（并且自相矛盾地难以找到）是在 if 语句之后添加额外的指令并忘记添加括号......
所以我喜欢 Resharper 的提议。特别是在嵌套 if 语句时：
假设我们有这个代码：
if (condition1) {
instruction1;
}
else {
if (condition2) {
instruction2;
}
}
它可以更改为如下所示：
if (condition1) {
instruction1;
}
else if (condition2) {
instruction2;
}
这对我来说比以前更具可读性。
（当您有超过 2 级的嵌套语句时，它也会更加明显）
我注意到 ReSharper 也有同样的事情，所以我很欣赏它能够关闭某些项目或降低其警告级别。我也对这个建议感到困惑：
SomeClass varName = new SomeClass();
建议更改为：
var varName = new SomeClass();
是的，我知道我不需要初始声明类型，但建议 var 形式在某种程度上比另一种更好，这感觉很奇怪。是否有人熟悉该建议背后的基本原理，或者您是否同意我的观点，即这个建议也很奇怪？
当您使用小样本量时，所有情况都会出现异常的经典示例。将一个巨大的 if-elseif-else 块重构为保护子句布局使代码更具可读性，但是，正如您所说，如果您将相同的规则应用于单个 if-else，它就没有那么有用了。我什至可以说，reshaper 开发人员（略微）缺乏远见，不要跳过像这样的非常小的块，但它是无害的。
作为 C# 的菜鸟，更习惯于 C 和 Java，我仍然无法习惯在 C# .NET 和 VS 中放置尖括号。抛开所有这些，我同意安德烈的观点，即颠倒“如果”更具可读性。另一方面，我个人发现省略“else”会降低可读性（稍微）。我会亲自去：
static public string ToNonNullString(this XmlAttribute attr)
{
if (attr == null)
return string.Empty;
else
return attr.Value;
}
我唯一要补充的是所涉及的表达式的长度。就个人而言，我喜欢三元表达式的紧凑性，但转而类似于
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;
似乎对我没有帮助。
当谈到最佳实践和编码标准时，它总是有争议的。原因之一是它们不能很容易地使用像 Visual Studio 这样的 IDE 来实施。有可用的工具，如 FxCop 和 StyleCop，可用于分析标准代码。FxCop 用于编译代码分析，StyleCop 用于源代码分析。
您可以将 StyleCop 配置到分钟级别，以决定您希望将哪种格式应用于代码。有一个名为 StyleCop for Resharper 的加载项，它在 Visual Studio 中提供建议。我在 http://nileshgule.blogspot.com/2010/10/refactoring-clean-code-using-resharper.html有一篇关于相同内容的详细博客文章
resharper 版本更好，因为 'attr != null' 条件可以被视为早期救助（或用例异常路径），允许函数继续其主要任务。（也没有赢得我的击掌，我讨厌多次回报）。
在这种情况下，我会说 MrWiggles 单线是最好的选择。
我的一些同事从那一刻开始在他们编辑的页面上使用 Resharper，但页面的布局和可读性很糟糕。我很高兴地说它没有生存下来，这里没有人再使用它了。
关于手头的陈述，我同意 Jeffrey Hantin 的观点，inline-if 非常适合这种类型的陈述，而且 Whatsit 的解决方案非常适合。除了一些例外，我（个人）说方法/函数应该只有 1 个返回语句。
此外，如果你（几乎）总是用你的 if 实现 else （即使它只是一个注释行，说明你在 else 语句中什么都不做）它会迫使你考虑这种情况，通常情况下它可以防止错误。
这两句话都应该用作“思考”而不是规则，就像大多数此类问题一样，请始终使用您的大脑:) 大多数错误发生在您不这样做时。
结论：对 Resharper 说不！（是的，我真的不喜欢 Resharper，抱歉。）