由Resharper代码build议使代码不易读？
当试图达到所有绿色，我收到了Resharper以下build议。
原始码：
static public string ToNonNullString(this XmlAttribute attr) { if (attr != null) return attr.Value; else return string.Empty; } build议：删除多余的“其他”导致以下内容：
static public string ToNonNullString(this XmlAttribute attr) { if (attr != null) return attr.Value; return string.Empty; }
对我来说，build议的版本似乎不如原来的可读性。 Resharper的build议是否反映了良好可维护代码的定义？
技术上来说，Resharper是正确的，因为“其他”是不必要的，我更喜欢以前的版本，但意图更明显。
话虽如此，我宁愿与：
return attr != null ? attr.Value : string.Empty;
啊，代码美学。 圣战时间。 （鸭）
我会用一个？：expression式去：
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; }
由于您的原始版本太对称，而空案例是一个特例。
新版本在“大部分时间返回什么”方面更具可读性。
我同意你的代码的第一个版本更具可读性。
在这些案例中，我发现了Resharper的build议并不总是有帮助的，尽pipe有时它可以清理干净。 这就是为什么我已经configuration了Resharper，以显示更改为“提示”而不是“build议”。 这会导致绿色下划线变得不可见，并且不会在右侧边栏突出显示。
如果您不喜欢ReSharperbuild议的方式， 只需禁用特定的build议 （斜杠警告斜线提示）。 编码风格也是如此，我认为这是相当高度可configuration的 。 声称ReSharper是无法使用的（引用“我很高兴地说，它没有生存，没有人在这里使用它了”），只是因为你不花5分钟才能知道如何configuration它只是简单的愚蠢 。
当然，你不应该让某些工具指定你的编码风格的一部分，如果你不告诉它，ReSharper是不会这么做的。 就这么简单。
您的原始代码更具可读性和可理解性 – 一眼就可以看到导致string.Empty返回的条件。 没有else ，你必须看到，在这之前， if区块有一个回报。
只要记住，你是一个人，比机器本身更聪明。 如果它告诉你一些更好，你不同意，那么不要听它。
我的编码标准总是使用括号（即使if命令后只有一个指令）
这需要一些努力（更多的打字），但我经常相信，这是非常值得的！
最常见的错误之一（矛盾地难以find）是在if语句之后添加额外的指令并忘记添加括号。
所以我喜欢Resharper提出的。 特别是当嵌套if语句时：
假设我们有这样的代码：
if (condition1) { instruction1; } else { if (condition2) { instruction2; } }
它可以改变看起来像这样：
if (condition1) { instruction1; } else if (condition2) { instruction2; }
而且这对我来说更可读。
（当你有两个以上的嵌套语句时，它也会更明显）
我注意到了ReSharper的相同的东西，所以我很欣赏它能够closures某些项目或降级警告级别。 我也对这个build议感到困惑：
SomeClass varName = new SomeClass（）;
build议更改为：
var varName = new SomeClass（）;
是的，我知道我不需要最初的声明types，但是觉得这个var的forms比另一个更好 。 有人对这个build议背后的理由有所了解吗，或者你是否同意我的看法呢？
当您使用小样本大小时，经典的例外情况会蔓延到一切。 将一个巨大的if-elseif-else块重构成一个guard子句布局使得代码更具可读性，但是，正如你所说的，如果你将相同的规则应用于单个if-else，那么它就不是那么有用。 我甚至可以说这是一个（轻微）缺乏远见的，而不是跳过像这样的非常小的块，这是无害的。
成为C＃的noob，更习惯于C和Java我还是不习惯在C＃.NET和VS中使用尖括号。 把所有这一切放在一边，我同意安德烈在反转“如果”更可读。 另一方面，我个人发现，省略“其他”会降低可读性（略）。 我会亲自去：
static public string ToNonNullString(this XmlAttribute attr) { if (attr == null) return string.Empty; else return attr.Value; }
我所添加的唯一的东西将不得不涉及expression式的长度。 就我个人而言，我喜欢三元expression式的紧凑性，但是转向类似的东西
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用于源代码分析。
您可以将StyleCopconfiguration为一个分钟级别，以确定要应用于代码的格式。 还有一个名为StyleCop的插件，用于在Visual Studio中提供Suggessions。 在http://nileshgule.blogspot.com/2010/10/refactoring-clean-code-using-resharper.html上有详细的博客文章;
resharper版本更好，因为'attr！= null'条件可以被看作是一个早期的救援（或用例exceptionpath），允许函数继续执行其主要任务。 （既不赢得高五，我讨厌多重回报）。
在这种情况下，我会说MrWiggles单线是最好的select。
我的一些同事从那个时候开始在他们编辑的页面上使用了Resharper，在布局和可读性方面都很糟糕。 我很高兴地说，它没有生存，没有人在这里使用它了。
关于手头上的声明，我同意Jeffrey Hantin，内联 – 如果这样的声明非常好，Whatsit的解决scheme是非常适合的。 除了一些例外，我（personaly）说，方法/函数应该只有1个返回语句。
另外，如果你（几乎）总是用你的if来实现else（即使它只是一个注释行，说明你对else语句没有做任何事情），它会迫使你考虑这种情况，通常它可以防止错误。
这两种说法都应该用作“思考”，不像大多数这样的问题，总是用你的大脑:)大多数错误发生在你不这样做的时候。
总之：对Resharper说不！ （是的，我真的不喜欢Resharper，对不起。）
