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

【问题标题】：Code suggestions by Resharper making code less readable?Resharper 的代码建议使代码的可读性降低？
【发布时间】：2015-11-10 01:04:33
【问题描述】：

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

【问题讨论】：

尝试全绿时
C# 6.0 变体：return attr?.Value ?? string.Empty;
需要对 R# 和 Roslyn 分析器等工具进行配置，以使其适合您（或您的团队）的偏好。如果您使用 Roslyn 分析器，您可以在 .editorconfig 文件中配置这些首选项并将它们提交到您的存储库，所有团队成员都会选择它们，无论他们是否安装了 R#。

标签： c# resharper

【解决方案1】：

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

话虽如此，我宁愿选择：

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

【讨论】：

提高可读性的三元运算符是吗？ 火神眉毛挑眉
+1，是的，我觉得它更具可读性 - 为什么人们如此害怕条件运算符？
因为我必须寻找运算符符号来查看不同的部分是什么。
+1，对于这些类型的条件，我发现三元运算符比 if-else 更具可读性。
为了提高较长行的可读性（您可能不会将其识别为三进制，我通常在 ? 和 : 字符之前添加换行符，因此每个替代结果都在自己的行上，它仍然是小巧紧凑，同时也非常易读。

【解决方案2】：

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

我会使用 ?: 表达式：

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

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

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

return attr.Value;

【讨论】：

【解决方案3】：

如果你把 if 倒过来，我觉得新版本会好很多

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

    return attr.Value;
}

因为你原来的版本太对称了，而 null-case 是个特例。

新版本在“它大部分时间返回什么？”方面更具可读性。

【讨论】：

【解决方案4】：

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

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

【讨论】：

+1 用于建议将检查降级为提示。我认为在这种情况下，一个保护子句更可取，但有时为了对称起见，我更愿意留下多余的else。

【解决方案5】：

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

当然，您不应该让某些工具支配您的编码风格的某些部分，如果您告诉 ReSharper 不这样做，它就不会这样做。就这么简单。

【讨论】：

但是让这些 cmets // ReSharper 在我的代码中随处禁用 InconsistentNaming 等会影响可读性

【解决方案6】：

您的原始代码更具可读性和可理解性 - 一眼就能看出导致返回 string.Empty 的确切条件。如果没有else，你必须看到之前的if 块中有返回。

请记住，您是人类，天生就比机器聪明。如果它告诉你某件事更好，而你不同意，那就不要听它。

【讨论】：

【解决方案7】：

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

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

所以我喜欢 Resharper 的提议。尤其是在嵌套 if 语句时：

假设我们有这个代码：

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

可以改成这样：

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

这对我来说比以前更具可读性。
（当您有超过 2 级的嵌套语句时，它也会更明显）

【讨论】：

【解决方案8】：

我注意到 ReSharper 也有同样的情况，因此我很欣赏它能够关闭某些项目或降低其警告级别。我也对这个建议感到困惑：

SomeClass varName = new SomeClass();

建议更改为：

var varName = new SomeClass();

是的，我知道我不需要初始声明类型，但建议 var 形式在某种程度上比其他形式更好感觉很奇怪。是否有人熟悉该建议背后的基本原理，或者您是否同意我的观点，即这个建议也很奇怪？

【讨论】：

我也是，这就是为什么这是我在安装 resharper 时唯一更改的原因。我让它总是使用显式类型。
这更好，因为SomeReallyVerboselNamedClassWithAVeryLongName someReallyVerboselyNameClass = new SomeReallyVerboselyNamedClassWithAVeryLongName(); 比var 等价物更长且不那么整洁，但根本不包含任何可以帮助您阅读它的更多信息。

【解决方案9】：

当您使用小样本时，所有情况都会出现异常的经典示例。将一个巨大的 if-elseif-else 块重构为保护子句布局使代码更具可读性，但是，正如您所说，如果您将相同的规则应用于单个 if-else，它就没有那么有用了。我什至可以说，reshaper 开发人员（略微）缺乏远见，不会跳过像这样的非常小的块，但它已经足够无害了。

【讨论】：

【解决方案10】：

作为 C# 的菜鸟，并且更习惯于 C 和 Java，我仍然无法习惯在 C# .NET 和 VS 中放置尖括号。抛开所有这些，我同意安德烈的观点，即颠倒“如果”更具可读性。另一方面，我个人发现省略“else”会降低可读性（略微）。我会亲自去：

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

【讨论】：

【解决方案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;

似乎对我没有帮助。

【讨论】：

【解决方案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

【讨论】：

【解决方案13】：

resharper 版本更好，因为 'attr != null' 条件可以被视为早期救助（或用例异常路径），允许函数继续其主要任务。（也没有赢得我的击掌，我讨厌多次回报）。

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

【讨论】：

【解决方案14】：

我的一些同事从那一刻开始在他们编辑的页面上使用 Resharper，但页面的布局和可读性很糟糕。我很高兴地说它没有存活下来，这里没有人再使用它了。

关于手头的陈述，我同意 Jeffrey Hantin 的观点，inline-if 非常适合这种类型的陈述，并且 Whatsit 的解决方案非常适合。除了一些例外，我（个人）说方法/函数应该只有 1 个返回语句。

另外，如果你（几乎）总是用你的 if 来实现 else（即使它只是一个注释行，说明你在 else 语句中什么都不做）它会迫使你更多地考虑这种情况，而不是不是它可以防止错误。

这两种说法都应该用作“思考”而不是规则，就像大多数此类问题一样，请始终使用您的大脑:) 大多数错误发生在您不这样做时。

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

【讨论】：

那么除了代码提示和建议之外，ReSharper 的所有其他功能又如何呢？他们让我的生活变得轻松。此外，您可以将 ReSharper 配置为仅显示您同意的规则。
默认情况下，Resharper 会提出许多愚蠢的建议，将注意力从真正重要的事情上转移开，并经常导致代码质量低下。但正如其他人所说，如果您有很多时间，可以禁用或编辑这些功能。