36

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

4

14 回答 14

49

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

话虽如此,我宁愿选择:

return attr != null ? attr.Value : string.Empty;
于 2009-01-21T23:00:00.567 回答
31

啊,代码美学。圣战时期。(鸭子)

我会选择一个 ?: 表达式:

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

或反转 if 并删除换行符以生成保护子句

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

return attr.Value;
于 2009-01-21T23:08:30.983 回答
22

我认为如果您反转 if,新版本会更好

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

    return attr.Value;
}

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

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

于 2009-01-22T07:31:07.443 回答
10

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

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

于 2009-01-21T22:58:17.403 回答
8

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

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

于 2009-02-25T15:38:41.553 回答
4

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

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

于 2009-01-21T23:12:42.117 回答
3

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

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

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

假设我们有这个代码:

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

它可以更改为如下所示:

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

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

于 2010-08-25T07:10:16.793 回答
1

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

SomeClass varName = new SomeClass();

建议更改为:

var varName = new SomeClass();

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

于 2009-01-21T23:18:27.673 回答
1

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

于 2009-01-21T23:23:09.520 回答
1

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

static public string ToNonNullString(this XmlAttribute attr)
{    
    if (attr == null)
        return string.Empty;
    else
        return attr.Value;
}
于 2009-02-25T15:31:29.900 回答
1

我唯一要补充的是所涉及的表达式的长度。就个人而言,我喜欢三元表达式的紧凑性,但转而类似于

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;

似乎对我没有帮助。

于 2010-08-23T15:23:42.703 回答
1

当谈到最佳实践和编码标准时,它总是有争议的。原因之一是它们不能很容易地使用像 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有一篇关于相同内容的详细博客文章

于 2010-10-06T11:39:22.477 回答
1

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

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

于 2012-02-22T15:10:30.533 回答
0

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

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

此外,如果你(几乎)总是用你的 if 实现 else (即使它只是一个注释行,说明你在 else 语句中什么都不做)它会迫使你考虑这种情况,通常情况下它可以防止错误。

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

结论:对 Resharper 说不!(是的,我真的不喜欢 Resharper,抱歉。)

于 2009-01-22T07:52:41.253 回答