Question

在尝试使用绿色时，我得到了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建议是否反映了良好可维护代码的定义？

Answer 1

技术上的Resharper是正确的，因为“else”是不必要的，我更喜欢前一版本，因为意图更明显。

话虽如此，我宁愿选择：

return attr != null ? attr.Value : string.Empty;

Answer 2

啊，代码美学。圣战时间。 （鸭）

我选择？：表达式：

return attr != null ? attr.Value : String.Empty

或反转if并删除换行符以生成guard clause：

if (attr == null) return String.Empty;

return attr.Value;

Answer 3

我认为如果你反转if

，新版本要好得多

static public string ToNonNullString(this XmlAttribute attr)
{
    if (attr == null)
        return string.Empty;

    return attr.Value;
}

因为您的原始版本太对称，而null-case是一种特殊情况。

新版本在“大部分时间返回的内容”方面更具可读性。

Answer 4

我同意您的代码的第一个版本更具可读性。

我发现在这些情况下Resharper的建议并不总是有用，尽管有时它可以清理。这就是为什么我配置Resharper将变化显示为“提示”而不是“建议”。这会导致绿色下划线不太明显，并且不会在右侧边栏中突出显示。

Answer 5

如果您不喜欢ReSharper建议的方式，只需禁用特定建议（斜线警告斜线提示）。编码风格也是如此，我认为它非常高度可配置。声称ReSharper无法使用（引用“我很高兴地说它无法生存，此处没有人再使用它了”）只是因为你不花5分钟就知道如何配置它只是普通的愚蠢

当然你不应该让某些工具决定你的编码风格的某些部分，而ReSharper如果你告诉它不要这样做。就这么简单。

Answer 6

您的原始代码更具可读性和可理解性 - 一目了然，您可以准确地看到导致string.Empty返回的条件。如果没有else，您必须在此之前看到if块中有返回。

请记住，你是一个人，而且比机器本身更智能。如果它告诉你某些事情更好并且你不同意，那么就不要听它。

Answer 7

我的编码标准总是使用括号（即使命令后只有一条指令）
这需要一点点努力（更多打字），但我经常相信它是非常值得的！

最常见的错误之一（并且很难找到）是在if语句之后添加额外的指令而忘记添加括号...

所以我喜欢Resharper提出的建议。特别是在嵌套if语句时：

假设我们有这段代码：

   if (condition1)  {
      instruction1;
   }
   else {
       if (condition2) {
           instruction2;
       }
   }

可以将其更改为：

   if (condition1)  {
      instruction1;
   }       
   else if (condition2) {
      instruction2;
   }

之前我对此更具可读性 （当你有超过2级的嵌套语句时，它也会更明显）

Answer 8

我已经注意到ReSharper的相同之处，所以我很欣赏它能够关闭某些项目或降级警告级别。我也对这个建议感到困惑：

SomeClass varName = new SomeClass（）;

建议更改为：

var varName = new SomeClass（）;

是的，我知道我不需要初始声明类型，但建议var表单以某种方式更好而不是另一种表示感觉很奇怪。是否有人熟悉该建议背后的理由，或者您是否同意我这一点也很奇怪？

Answer 9

当您使用较小的样本量时，异常的典型示例会蔓延到所有内容中。将一个巨大的if-elseif-else块重构为一个保护子句布局使得代码更具可读性，但正如你所说，如果你将相同的规则应用于单个if-else，那么它就没那么有用了。我甚至可以说这是一个（轻微的）缺乏远见的重新开发者开发者不要跳过像这样的非常小的块，但它足够无害。

Answer 10

作为C＃的菜鸟并且更习惯于C和Java我仍然不习惯在C＃.NET和VS中放置尖括号。把所有这些放在一边，我同意安德烈的说法，反过来'if'更具可读性。另一方面，我个人发现省略'else'会降低可读性（略）。我个人会这样做：

static public string ToNonNullString(this XmlAttribute attr)
{    
    if (attr == null)
        return string.Empty;
    else
        return attr.Value;
}

Answer 11

我要添加的唯一内容是必须使用所涉及的表达式的长度。就个人而言，我喜欢三元表达式的紧凑性，但转向类似

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;

对我来说似乎没什么帮助。

Answer 12

在最佳实践和编码标准方面，它始终存在争议。其中一个原因是使用像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

Answer 13

resharper版本更好，因为'attr！= null'条件可以被视为早期救助（或用例异常路径），允许该功能继续其主要任务。（既不赢得我的高五，又讨厌多次回报）。

在这种情况下，我会说MrWiggles单线是最好的选择。

Answer 14

我的一些同事从那时起开始使用Resharper，他们编辑的页面布局和可读性都很糟糕。我很高兴地说它没有生存，没有人在这里使用它了。

关于手头的陈述，我同意Jeffrey Hantin，内联 - 如果对这种类型的陈述非常好，并且Whatsit的解决方案非常适合。除了一些例外，我（personaly）说方法/函数应该只有1个return语句。

此外，如果你（几乎）总是用你的if实现else（即使它只是一条注释行，说明你在else语句中什么也没做），它会强迫你考虑这种情况，不是它可以防止错误。

这两个评论都应该被用作“思考”而不是规则，就像大多数这类问题一样，总是使用你的大脑:)大多数错误都发生在你不这样做的时候。

总结：对Resharper说不！（是的，我真的不喜欢Resharper，抱歉。）

Resharper的代码建议使代码可读性降低？

14 个答案: